CC BY
8
УДК 004.043
МЕТОД ОРГАШЗАЦП ФУНКЦ1Й КОНТРОЛЕРА SDN «НЕСК1НЧЕННИЙ ПОТЯГ»
СКУЛИШМ. А._
Описуеться використання хмарного середовища для програмно визначених мереж, що вiдкривае новi мо-жливосп для оргашзацп обчислювального процесу мережевих контролерiв. Пропонуеться метод серв1с-них прикладних програм для виконання функцш контролера SDN. Описуеться метод керування ресурсами вiртуальних машин, який дозволяе обслуговувати велику к1льк1сть додатшв одночасно без затримки завдяки балансуванню навантаження. Ключовi слова: програмно визначена мережа, Software Defined Network, контролер SDN, балансу-вання навантаження контролера. Вступ
Швидке зростання трафша i змша його структу-ри, необхiднiсть пiдтримання велико! кшькосп мобiльних користувачiв та створення високопро-дуктивних кластерiв для обробки великих обся-гiв даних i добре масштабованих вiртуалiзова-них середовищ для надання хмарних сервiсiв -вс цi речi серйозно змiнили вимоги до мережевих середовищ. Таким чином, дуже часто мережа стае обмежуючим фактором у розвитку обчис-лювально! шфраструктури.
Основна проблема полягае в тому, що традицшш мережi занадто статичш, внаслiдок цього вони не вщповщають динамiцi поточного процесу розпо-дiлу, на вiдмiну вщ серверiв, чим останнi зобов'-язаш технологiям вiртуалiзацil. На сьогоднiшнiй день прикладш програми розподiляються мiж декшькома вiртуальними машинами, що штен-сивно обмшюються даними (що призводить до збшьшення трафiку захiд-схiд, який починае домiнувати над традицiйним для клiент-серверних архiтектур трафiком пiвнiч-пiвдень). Для оптимiзацil завантаження серверiв вiртуаль-ш машини часто мiгрують, що змшюе точки «прив'язки» трафiка. Традицiйнi схеми адресаци, логiчного подiлу мереж i способи призначення правил обробки трафша в таких динамiчних се-редовищах стають неефективними. Схожi труднощi виникають i з реконф^уращею механiзмiв Quality of Service (QoS) при додаванш в мультисервiсну мережу ново! прикладно! програми, наприклад вiдеозв'язку. Занадто багато часу у великих мережах займають процедури зi змiни параметрiв захисту, що не дозволяе оперативно реагувати на виникаючi загрози [1]. Впровадження технологш програмно-конфiгурованих мереж та вiртуалiзацil мережевих функцiй може стати саме тим фактором, який дозволить виршити iснуючi проблеми i радикально змшити пiдхiд до оргашзаци та керу-вання мережею.
1. Огляд технологи програмно-визначених мереж
Пщ програмно-визначеною мережею (Software-defined Networking, SDN) розумдать мережу пе-редачi даних, в якш рiвень управлiння вiддiлений вiд пристро!в передачi даних i реалiзуеться програмно; вона являе собою одну з форм вiртуалi-заци обчислювальних ресурав. Данi передаються вiдповiдно до таблиць марш-рутизаци, що збер^аються на апаратних системах, як i згiдно з iснуючими тдходами. Але цi таблицi централiзовано управляються вщдале-ною системою, у зв'язку з чим зникае необхщ-шсть змiнювати таблицi на кожному комутаторi окремо. В iдеальному випадку вс мережевi ком-поненти повиннi управлятися i налаштовуватися в ходi одше! операци. Спiльна робота компонен-пв програмно-обумовлено! мереж може бути заснована на стандарт OpenFlow. Ключовi принципи SDN - подш процесiв пере-дачi та управлiння даними, централiзацiя управ-лiння мережею за допомогою ушфшованих про-грамних засобiв, вiртуалiзацiя фiзичних мережевих ресурсiв. Протокол OpenFlow, який реалiзуе незалежний вщ виробника iнтерфейс мiж лопч-ним контролером мережi i мережевим транспортом, е одшею з реалiзацiй концепци програмно-конф^уровано!' мережi [2].
Головна щея SDN полягае у вщокремленш фун-кцiй передачi трафiка вiд функцiй управлiння (включаючи контроль як самого трафша, так i пристро!в, що здiйснюють його передачу). У традицшних комутаторах i маршрутизаторах цi процеси невiддiльнi один вщ одного i реалiзованi в однш «коробщ»: спецiальнi мiкросхеми мере-жевого обладнання забезпечують пересилання пакеив з одного порту на шший, а вищерозмi-щене програмне забезпечення визначае правила такого пересилання, виконуе необхiдний аналiз пакетiв, виконуе змiну службово! шформаци, що мютиться в них. Для визначення маршруту пере-дачi або недопущення зациклення трафiка при-стро!, звичайно, обмшюються мiж собою даними, для чого розроблено безлiч протоколiв, таких як Open Shortest Path First (OSPF), Border Gateway Protocol (BGP) i Spanning Tree, але при цьому кожен пристрш функцюнуе досить автономно.
На рис. 1 схематично зображена концепщя SDN, зпдно з якою вся лопка управлшня виноситься в так зваш контролери, яю здатнi вiдстежувати роботу всiеl мережi.
Прикладнии pi&ïHb [
Бинвс-лолагкн
уи_hp_
Контрольная fflHHHH
ршгнь ИРСщД Мереж. cepBÎc
I OpenFlow Нежь шфряетруиури J,
| Ы5р5ж npKirpiÈ I Jsi^piHC. ITpKirpiil I XEspîHî.npKrrpiii |
EpKOpiK ■ M^pis irposcrpii
Рис. 1 .Концепщя технологп програмно-конфкурованих мереж Основною рушшною силою концепцн програм-но-конфнурованих мереж та базовою складовою И арх1тектури е протокол Open Flow. Open Flow - це протокол, завданням якого е ке-рування мережевими пристроями за допомогою SDN-контролера. Це надае можливють безпосе-реднього програмування мережевого обладнання (наприклад, комутатор1в i маршрутизатор1в), як ф1зичного, так i в1ртуального, що робить мережу бшьш динам1чною i контрольованою. Основною характеристикою протоколу Open Flow е вико-ристання потоюв для щентифшацн мережевого трафша. Ц потоки засноваш на заздалегщь ви-значених правилах, яю можуть бути статично або динам1чно запрограмоваш за допомогою SDN-контролера [3].
Показники якост функщонування програмно-керованих мереж залежать вщ швидкодп про-грамних модул1в, яю реал1зують мережев1 функ-цн. Передбачаеться, що використання хмарних технологш забезпечить потреби у обчислюваль-них ресурсах програмно-керованих мереж. На сьогодшшнш день ощнити стутнь завантажено-ст обчислювальних ресурс1в, що шдтримують функщонування програмного забезпечення контролера, можна лише теоретично. Запропонова-ний у данш статп метод несюнченного потягу дозволить оргашзувати обчислювальш процеси програмно-керованих мереж таким чином, щоб максимально використати можливосп сучасного обчислювального середовища. 2. Основш функцп р1вня управлiння мереж1 SDN
Розглянемо бшьш детально р1вень управлшня мереж1 SDN. Основними елементами р1вня управлшня е контролери. Контролер SDN являе собою новий клас продукту мереж передач! да-них. На рис. 2 описано десять ключових характеристик функщональних можливостей контролера SDN.
ЁШЯоВЭ: : ^Э : I
ЦЩЧЩ^ЦШ ЕТГча^^^^^^р ■
I ^—| [ ^^И <^zzi[ -фщ
Рис. 2. Ключов1 функцюнальш характеристики контролера SDN
1. Шдтримка протоколу Open Flow. Коли пакет надходить на комутатор Open Flow, поля заголовка порiвнюються з потоком запишв таблищ. Якщо знайдено спiвпадiння, то пакет передасться на вказаний порт або опускаеться, залежно вiд одша або декiлькох дiй, збережених в таблищ потоюв. Коли комутатор Open Flow приймае пакет, який не вщповщае запису таблищ потоку, вш формуе пакет i передае його на контролер. По^м контролер виршуе, яким чином пакет повинен бути оброблений, i повщомляе комута-тор проскинання пакета та створення нового запису в таблищ потоку для шдтримки нового потоку.
2. Вгртуалгзацгя мереж!. Одним з найбшьш важ-ливих переваг контролера SDN е вiртуалiзацiя мережа Одним iз типiв вiртуалiзацiï мережi, який використовувався у виробничих мережах протя-гом багатьох десятилт, е вiртуальна локальна мережа (VLAN). Мережi VLAN роздiлили мережу Ethernet на щлих 4094 широкомовних доменiв i стали зручним засобом видшення рiзних типiв трафiка, яю дiлять одну й ту ж LAN шфраструк-
туру.
3. Функцгональтсть мережi. З метою безпеки провайдери хмарних послуг прагнуть бути iзо-льованими одне вщ одного. Для того щоб ефек-тивно виконати цю вимогу, контролер SDN повинен включати вiртуальнi мереж^ повнiстю iзольованi одна вiд одно].', як конфiгуруються централiзовано з можливютю автоматичного застосування конфiгурацiй.
4. Масштабовамсть. Традицшна локальна мережа розгортаеться в багаторiвневу архiтектуру, в якш функцiя маршрутизацiï 3-го рiвня викори-стовуеться для пiдключення багатьох мереж 2-го рiвня. Такi традицiйнi локальш мереж не дуже добре масштабуються при пiдтримцi трафiка захiд-схiд, оскшьки принаймнi один пристрiй 3-го рiвня, а швидше за все багато пристро'в 3-го рiвня перебувають на шляху «з кiнця в кшець». Ключовим фактором, який вщноситься до масш-табованостi SDN, е кшьюсть комутаторiв, якi може тдтримувати контролер SDN. У поточному середовищi контролери повиннi пiдтримувати як мшмум 100 комутаторiв, але ця цифра зале-жатиме вiд сценарнв використання SDN, якi пiд-тримуються в даний час.
5. Продуктивтсть. Одшею з ключових функщй контролера SDN е створення потокiв. Таким чином, два з ключових показниюв продуктивностi, пов'язаних з контролером SDN, е час створення потоку i кшьюсть потоюв за секунду, яю може створити контролер. Ц показники продуктивно-eri значною мiрою впливають на необхщшсть розгортання додаткових контролерiв SDN. На-
приклад, якщо комутатори SDN шщдають бшь-ше потоюв, нiж може шдтримуватися iснуючим контролером(ами) SDN, потрiбно додати бшьше контролерiв.
6. Програмовашсть мережа. 1ншим прикладом типу програмованостi мережi е можливiсть за-стосування складних фiльтрiв для пакетiв. Цi фшьтри можна розглядати як динамiчнi, штелек-туальнi списки ACL. Простi списки контролю доступу можуть бути засноваш на безпосеред-ньому узгодженнi заголовка пакета i можуть використовуватись для визначення необхщносп видiлення чи передачi пакетiв. На противагу цьому, контролер SDN повинен мати можливють застосовувати фшьтри, що складаються зi складних комбшацш декiлькох полiв заголовка пакета. Фшьтри повинш динамiчно розгортатись у вiр-туальних мережах, а роль контролера SDN поля-гае у тому, щоб проштовхувати вiдповiднi записи таблиц вниз до комутаторiв. Контролер SDN може також тдтримувати програмованiсть, на-даючи шаблони, якi дозволяють створювати сце-нарн CLIs, що, на вщм^ вiд традицiйного управлшня конфiгурацiями, дозволить динамiчно програмувати мережу.
7. НадШшсть. Повинно юнувати декiлька мере-жевих шлях1в вiд пункту вiдправлення до пункту призначення. Контролер SDN також повинен бути побудований з використанням функцш ре-зервування апаратного i програмного забезпе-чення, контролери повинш мати можливють об'еднуватись у кластери.
8. Безпека мереж1. Повинна бути забезпечена можливють застосувати аутентифшашю та авто-ризашю корпоративного класу i повнiстю iзолю-вати кожну вiртуальну мережу. Контролер SDN повинен мати можливють обмежити швидкють передачi контрольних повщомлень.
9. Централ1зоване управления i в1зуал1зац1я. Контролер SDN повинен вибрати класи трафша, яю вiн контролюе, i представити вiзуалiзацiю фiзич-но! мережi та кшькох вiртуальних мереж, що працюють на ньому.
10. Вендор контролера SDN. Постачальник повинен продемонструвати, що вiн мае фiнансовi та технiчнi ресурси для тдтримки постiйного розвитку, який буде пов'язаний з мережею SDN. Постачальник повинен також продемонструвати свою довгострокову позицiю i iмпульс на ринку SDN.
Кожна з цих функцш може бути представлена у виглядi набору процедур, яю виконуються в об-числювальному середовищi. Продуктивнiсть i надiйнiсть процедур залежить вiд оргашзацн обчислювального середовища.
3. Оргашзащя обчислювального процесу в контролер1 SDN
Контролери в програмно-визначенш мережi (SDN) вщирають роль !! «мозку». Це програма, яка виступае як стратепчна точка курування в мережi SDN, скеровуе потоки управлшня до ко-мутаторiв/маршрутизаторiв«вниз» (через API пiвденного напрямку) та прикладних програм i бiзнес-логiки «вгору» (через API пiвнiчного напрямку) для розгортання iнтелектуальних мереж. Останшм часом, оскiльки органiзацil розгорта-ють все бiльше мереж SDN, контролерам було додано задачу об'еднання доменамi в SDN з використанням загальних iнтерфейсiв прикладних програм, таких як Open Flow i вщкрита вiртуаль-на база даних комутатора (OVSDB)[4]. На сьогоднiшнiй день юнуе два основних пiдхо-ди до оргашзацн обчислювального процесу ро-боти контролера. Перший [5] забезпечуе оргаш-зацiю безлiчi контролерiв, кожен з яких предста-вляе собою незалежний обчислювальний вузол зi своею власною системою управлшня. Другий шдхщ [6] передбачае кластерну органiзацiю контролера, де ключовим завданням е балансування навантаження. Завдяки використанню хмарних технологш, продуктивнiсть рiзних кластерiв можна вважати умовно-несюнченною. ^HmpaMi3oeaHe планування навантаження KOHmpoMepie
Одна з щей, яю активно розвиваються в рамках SDN, це вiртуалiзацiя мереж для бшьш ефектив-ного використання мережевих ресуршв. Вiртуа-лiзацiя мережi вщноситься до iзоляцil мережево-го трафша - групування (мультиплексування) декiлькох потоюв даних з рiзними характеристиками в межах одше! логiчноl мереж, яю можуть спiльно використовувати едину фiзичну мережу з iншими мережами або з лопчними зрiзами мереж. Кожен зрiз може використовувати сво! ал-горитми адресацil та маршрутизацн, керування якiстю обслуговування.
Перший метод оргашзацн контролера SDN передбачае, що лопка управлшня кожно! вiртуаль-но! мережi може працювати на контролерi, а не на ф1зичних комутаторах (рис.3).
Комлтатор
О О О О О О О О
Щ Планувальник
/7 W.
□ сто
Контролери
Рис. 3.Централ1зоване планування навантаження контролер1в
SDN надае гнучкий та простий cnoci6 визначен-ня вiртуальних мереж, представляючи кожне вiртуальне з'еднання у виглядi потоку, отже, ви-значаючи вiртуальну мережу як набiр правил потоку в рiзних комутаторах. Таким чином, площина управлiння SDN може бути використа-на для досягнення важливих пол!тик розподiлу ресурсiв, таких як балансування навантаження мережi, мiнiмiзацiя витрат ресурс!в. Наприклад, Flowvisor [7] i XNet Mon [8] дають можливють декiльком орендарям роздiлити основу мережi SDN за допомогою в!ртуал!заци, дозволяючи iзоляцiю та спiльне використання мережевих зрiзiв.
Одним i3 прикладiв в!ртуал!заци SDN, подiлу мереж! на частини i програми управлiння е Flow Visor - програма-посередник (проксi-сервер), що працюе на рiвнi мiж Open Flow -комутаторами i рiзними контролерами SDN. За допомогою Flow Visor можна створювати лопчш сегменти мере-жi, якi використовують рiзнi алгоритми для уп-равлiння потоком даних, забезпечуючи iзоляцiю даних мережi один вщ одного. Це означае, що кожен контролер управляе тiльки його лопчною мережею i не може вплинути на шшу операцiю. Для контролера, що взаемодiе з навколишшм середовищем через протокол OpenFlow за допомогою FlowVisor, всi повщомлення виглядають так само, коли контролер взаемодiе зi звичайною мережею SDN. Всю необхщну модифiкацiю по-вщомлень, потрiбних для пiдтримки декiлькох iзольованих сегментiв мережi, виконуе Flow Visor. Це означае, що для лопчних модифшацш мережi пiдiйде будь-який контролер SDN, наприклад, мережева операцшна система, така як NOX, з будь-яким набором програм [5]. Однак в даний час не юнуе жодного ршення проблем управлшня ресурсами в оргашзаци контролера. Залишаються невирiшеними деякi важ-ливi питання резервування i вивiльнення обчис-лювальних ресуршв залежно вiд навантаження. SDN вже придшялась увага у [7, 9], де пропону-валися тюно пов'язанi пiдходи, заснованi на про-токолi Open Flow, з метою спшьного використання однiеi площини апаратних засобiв для пе-редачi даних мiж кiлькома логiчними мережами. Але там не розглядалася можливють використання умовно-несюнченних обчислювальних ресурсiв.
Кластерна оргашзащя контролера SDN Другий тдхщ передбачае кластерну органiзацiю контролера, де ключовим елементом операцп е балансування навантаження. Компашя Fujitsu Laboratories розробила модуль розподшеного управлшня для скоординованого управлшня безлiччю контролерiв, а саме техно-логiю балансування навантаження. Вона перед-
бачае передачу керуючого комутатора з одного контролера на шший шд час зростання навантаження або за наявносп пошкоджень i безперерв-но! технологii вiдновлення. Ц технологii дозво-ляють SDN надшно працювати зi збiльшенням рiвнiв трафша вище очiкуваного [10]. З розгортанням SDN з пiдтримкою технологiй, що стосуються глобально! мереж!, шфраструкту-ра отримуе змогу швидко вiдновлюватись в над-звичайних ситуацiях або тд час iнших збо!в мереж!, збершаючи при цьому здатнiсть до надшно! роботи мереж!.
Розподiлений кластерний контролер працюе на декшькох ф!зичних контролерах як единий лоп-чний контролер для управлшня декшькома ме-режевими комутаторами. У пор!внянш з тради-цшними централiзованими контролерами, клас-тернi розподiленi контролери забезпечують кра-щу масштабованiсть i вщмовостшкють. На сьо-годшшнш день проблема полягае в наявносп труднощ!в з обробкою р!зких коливань навантаження i з! скоординованим управлiнням у випад-ку збо!в контролера.
Fujitsu Laboratories розробила функщю перевiрки навантаження, як нове доповнення до модуля координацii розподшеного контролера (рис. 4). Вона збирае шформащю про навантаження вщ кожного компонента контролера (наприклад, про швидкють роботи процесора i кшькють комута-тор!в) (етап 1), а також система координаци пе-рюдично перевiряе iнформацiю про навантаження, використовуючи модуль координаци розпо-дiлених контролерiв як млiдерам на основ! контрольного номера модуля або шшого критерда (етап 2) для визначення навантаження дисбалан-с!в. Якщо необхщна змiна балансу навантаження, вщповщно до лопки балансування, комутатори перемикаються на основ! даних комутатора-перепризначення лопки для збалансування навантаження вщповщно до пол!тики коефщента завантаження центрального процесора i кшькосп перемикач!в (крок 3). В результат! вщповщнють м!ж змшеними комутаторами i контролерами рееструеться в систем! координаци (етап 4), а навантаження вр!вноважуеться перепризначен-ням комутатор!в вщповщно до оновлено! шфор-маци з розподшеного контролера (етап 5) [8].
Але ця технолопя також мае ряд недолшв. Роз-подшеш контролери на баз1 кластера вщр1зня-ються вщ централ1зованого контролера, оскшьки вс модул1 розподшеного управлшня повинш працювати узгоджено, щоб уникнути взаемно! конкуренцп. Ще одне завдання полягае в тому, щоб забезпечити безперервнють управлшня. Процеси повинш працювати нав1ть в раз1 виходу з ладу модуля. Але у випадку перевантаження деяких компоненпв або вщмови контролера ви-никають труднощ1 з автоматичним перемикан-ням i робота комутатор1в сповшьнюеться або стае нестабшьною.
Основним недолшом юнуючих шдход1в е те, що вони не розглядають можливють умовно-несюнченних обчислювальних ресурс1в. В результат система, побудована на основ1 обмеже-них ресурс1в, може мати перюди низько! якост обслуговування. Ц перюди пов'язаш з тим, що робота системи мошторингу включае в себе зб1р статистичних даних, показники якост усеред-нюються, i система очшуе перевищення порогового значення шдексу продуктивность Викорис-тання гетерогенних хмарних середовищ, а саме р1зних вид1в ршень для платформи як шфра-структури PaaS, дозволяе створювати i тдтри-мувати необмежену кшькють в1ртуальних машин, завдання яких полягае в тому, щоб викону-вати обчислювальш функцн контролера. 4. Метод оргашзацп функцiй «Нескшченний потяг»
На сьогодшшнш день юнуе декшька шдход1в до оргашзацп обчислювального процесу в контро-лер1 SDN. 1х основним недолшом е те, що вони не враховують можливють застосування необ-меженого ресурсу, який надають хмарш технологи. Yd юнуюч1 шдходи засноваш на тому, що кшькють ресурс1в системи е обмеженою i зале-жить вщ техшчних можливостей сервера, на якому розмщуються в1ртуальш машини. Наслщком застосування даних шдход1в стае зниження якост надання послуг в певш перюди часу, яю пов'язаш з тим, що робота системи мошторингу полягае у збиранш та анал1з1 даних про якють надання послуг в мережа Якщо значення параметр1в QoS для певних послуг е нижче порогового, але шш1 послуги надаються з досить високою якютю, система може не реагувати на зниження якост у певш перюди часу, оскшьки враховуеться лише середне значення показниюв. Виршенням дано! проблеми е застосування гетерогенного хмарного середовища, а саме певних ршень для платформи як шфраструктури (PaaS). Platform-as-Infrastructure являе собою 1зольова-ний кластер, що складаеться з групи сервер1в i сервю1в, яю взаемод1ють як цшюна система, на-даючи можливють зручно розгортати, тестувати,
шдтримувати i масштабувати систему. PaaS дозволяе створювати i обслуговувати необмежену кшькють вiртуальних машин, робота яких полягае в обслуговуванш обчислювальних функцш контролера. Застосування необмежено! кiлькостi ресуршв для роботи вiртуальних машин дозволить уникнути перiодiв зниження якост надання послуг.
Метод, що пропонуеться в данш статтi, назива-еться «ефект нескiнченного потягу». Його основна щея полягае в тому, що шсля того, як певна вiртуальна машина отримала на обслуговування задану кiлькiсть задач, створюеться нова вiртуа-льна машина, на яку надходять ус наступнi за-дачi (рис. 5).
Комутатор
1 //
Контролер SDN
Рис. 5.Метод «неск1нченного потягу»
Запропонований метод спираеться на метод ди-намiчноi мпрацп вiртуальних машин, розробле-ний компанiею Jelastic [11], що забезпечуе ба-лансування навантаження серверiв хмарного сховища даних за рахунок створення платформи для автоматичного керування контейнерами вiр-туальних машин. Також враховуеться метод ви-бору контейнера для мпрацп вiртуальних машин, описаний в статп [12], який дозволяе анал> зувати та прогнозувати навантаження на мережу на основi оцшки використовуваних ресурсiв. Застосування хмарного сховища даних передба-чае, що ус вони зберiгаються на великiй кшькос-тi розподiлених в мережi серверiв. При цьому повиннi виконуватись двi основнi задачi:
• 1нтерактивний розподш завдань клiентiв мiж вiртуальними машинами, яю розташованi в одному або декшькох кластерах. Це з одного боку завдання балансування навантаження, а з шшого - завдання забезпечення надшност обслуговування ктенпв;
• Контроль i управлiння роботою кластера вiр-туальних машин. Ресурсв кластера мае завжди вистачати всм вiртуальним машинам, якi одно-часно працюють на всiх серверах кластера. Метод «нескшченного потягу» передбачае, що вс заявки на обслуговування направляються до поточно! вiртуальноi машини до тих шр, поки вона не буде заповнена. Кшькють заявок, як
можуть бути оброблеш одшею вiртуальною машиною залежить вiд кiлькостi ресуршв, яка вид> ляеться 1й при створенш. Пiсля заповнення дано! машини створюеться нова, на яку перенаправляются усi наступнi заявки. Використання даного методу е можливим в тому випадку, якщо кшь-юсть ресурсiв системи е умовно необмеженою. Використання гетерогенного хмарного середо-вища надае таку можливiсть. Старi вiртуальнi машини продовжують обслуго-вувати сво! iнформацiйнi потоки до тих шр, поки 1х кiлькiсть не вичерпаеться. Пiсля цього вiртуа-льнi машини згортаються або очiкують на повто-рне введення в експлуатацiю як «пуст вагони». Максимальна кiлькiсть заявок, яю можуть обслу-говуватись у «вагош», залежить вiд конфнураци хмарно! платформи, або може бути отримана дослщним шляхом. Кiлькiсть заявок визначаеть-ся об'емом ресурсу, який використовуе контролер для виконання обчислювальних завдань. На максимальну кiлькiсть заявок також впливае гнучюсть процесiв мнраци - технiчних процесiв обслуговування вiртуальних машин. Iлюстрацiя описаного методу зображена на рис. 6.
НорожшМ • •—••
CP
влено мiтки контролю затримки. У pa3i невико-нання заданих умов навантаження мiж обслуго-вуючими пристроями пеpеpозподiлялося; - метод «нескшченний потяг» було змодельвано у виглядi системи масового обслуговування з несюнченною (дуже великою) кшьюстю обслу-говуючих пристро1в, кожна функщя оброблялася окремою групою обслуговуючих пристро1в. В pезультатi було отримано залежшсть (рис. 7).
Затримка, мс
х ID"*
Ой^иЛка (I Г>|1 лЁкй 1>н1 рш Гц;<
Рис.6. Ефект «несшнченного потягу»
п - максимальна кшьюсть задач для одше! УМ; к
- кiлькiсть задач, яю встигли обробитися у ^+2)-й вiртуальнiй машинi з початку 11 наповнення до поточного моменту, моменту завершення подачi заявок у вiртуальну машину (i+1); т - кшьюсть задач, якi встигли обробитися у ^+3)-й вiртуаль-нiй машиш з початку 11 наповнення до поточного моменту.
5. Дослщження ефективностi методу
З метою ощнки ефективностi запропонованого методу проведено iмiтацiйне моделювання у середовищi GPSS. Було оцiнено затримку обслу-говуваннi заявок на автентифшащю потоку, а також заявок на визначення оптимального шляху передачi iнформацiйного потоку. Було змодельо-вано роботу трьох методiв оргашзаци роботи контролерiв. А саме:
- централiзоване планування навантаження; та-кий метод було змодельовано у виглядi системи масового обслуговування з обмеженою кiлькiстю обслуговуючих пристро1в;
- оргашзащя кластерного контролера була спрощено змодельована у виглядi системи масового обслуговування з обмеженою кшьюстю обслуговуючих пристро1в, для яких було встано-
Рис. 7. Результати моделювання для трьох метод1в оргашзаци контролера SDN
Як видно з графшв, для методу несшнченного потягу затримка була найменшою. В той же час обмеженням дано! моделi е кшьшсть pесуpсiв, якi використовують для обслуговування. У данш статтi не дослщжувалася надлишкова кiлькiсть pесуpсiв, яка використовуеться для шщалзацл та функцiонування надлишково! кiлькостi вipту-альних машин. Висновки
Використання хмарних технологiй для забезпе-чення програмно-визначених мереж розкривае новi можливостi для оргашзаци обчислювальних пpоцесiв мережевих контpолеpiв. Методи обслуговування вipтуальних сутностей у хмарному сеpедовищi дозволяють розраховувати на умов-но-нескiнченнi обчислювальнi ресурси хмарного сервюу, який називаеться платформа як сервю. В той же час необхщно враховувати особливостi обслуговування вipтуальних сутностей на фiзич-ному обладнанш дата-центpiв. В pезультатi отримано метод обслуговування обчислювальних процешв у хмарному середови-щi, який називаеться «Несшнченний потяг». В pезультатi цього вс заявки на обслуговування (виконання функцш контролера) pоздiляються на блоки не бшьше заданого числа n, обслуговування цих заявок ведеться у окремш вipтуальнiй машинi. Кшьшсть вipтуальних машин несшнчен-на, тому вщсутня додаткова затримка пов'язана з перевантаженням частини обчислювальних ре-суршв, швидкiстю реакци систем балансування навантаження на знятi показники якост обслуго-вування.
Лггература:
1. Смелянский Р.Л. Программно-конфигурируемые сети / Р.Л. Смелянский // Открытые системы. СУБД.2012. No. 9. C. 23-26.
2. McKeown N. Openflow: Enabling innovation in campus networks / N. McKeown, T. Anderson// SIGCOMM Computer Communication Review. 2008. Vol. 38, no. 2. P. 69-74.
3. Lara A. Network Innovation Using OpenFlow: A Survey / A. Lara, A. Kolasani, B. Ramamurthy // IEEE Commun. Surv. Tutor. 2013. Vol. 16. P. 1-20. 4. SDN Controller Vendors.
https://www.sdxcentral.com/sdn/definitions/sdn-controllers/
5. Dynamic Resource Management in SDN-based Virtual-ized Networks/ Rashid Mijumbi, Joan Serrat, Javier Ru-bio-Loyolay, Niels Boutenz, Filip De Turckz and Steven Latr'ex // Universitat Polif ecnica de Catalunya, 08034 Barcelona, Spain.
6. Fujitsu Develops Cluster-Based Distributed Controller Technology to Implement Failure-Tolerant Wide-Area Software-Defined Networking / Fujitsu Laboratories Ltd. Kawasaki, Japan, June 05, 2014.
7. SherwoodR. Carving research slices out of your production networkswith openflow. SIGCOMM Comput. Commun. Rev., 40(1): 129-130, January 2010.
8. FernandesN.C. and O.C.M.B. Duarte. Xnetmon: A network monitorfor securing virtual networks. In Communications (ICC), 2011 IEEE International Conference on, pages 1-5, June 2011.
9. Drutskoy D., Keller E., and Rexford J. Scalable network virtualization in software-defined networks. Internet Computing, IEEE, 17(2):20-27, March 2013.
10. Chiosi M. Network Functions Virtualization: Network Operator Perspectives on Industry Progress / M. Chiosi, D. Clarke, C. Donley, et al. // Proceedings of SDN and OpenFlow World Congress, 15-17 October 2013, Frankfurt, Germany. Frankfurt, 2013. P. 1-16.
11. Ye K., Jiang X., Huang D. Live Migration of Multiple Virtual Machines with Resource Reservation in Cloud computing - IEEE International Symposium, 2013. Р. 267-274.
12. Pahl C., Xiong H. Migration to PaaS clouds - Migration process and architectural concerns - IEEE International Symposium, 2013. Р.86-91.
13. Jinkyu J. Sung-Hun K., Hwanju K. Analysis of virtual machine live-migration as a method for power-capping // The Journal of Supercomputing. 2013. Vol. 66, no 3. Р. 1629-1655.
Transliterated bibliography:
1. Smelyanskiy R.L. Programmno-konfiguriruemyieseti / R.L. Smelyanskiy // Otkryityiesistemyi. SUBD. 2012. No. 9. C. 23-26.
2. McKeown N. Openflow: Enabling innovation in campus networks / N. McKeown, T. Anderson// SIGCOMM Computer Communication Review. 2008. Vol. 38, no. 2. P. 69-74.
3. Lara A. Network Innovation Using OpenFlow: A Survey / A. Lara, A. Kolasani, B. Ramamurthy // IEEE Commun. Surv. Tutor. 2013. Vol. 16. P. 1-20.
4. SDN Controller Vendors. https://www.sdxcentral.com/sdn/definitions/sdn-controllers/
5. Dynamic Resource Management in SDN-based Virtual-ized Networks / Rashid Mijumbi, Joan Serrat, Javier Ru-bio-Loyolay, Niels Boutenz, Filip De Turckz and Steven Latr'ex // UniversitatPolif ecnica de Catalunya, 08034 Barcelona, Spain.
6. Fujitsu Develops Cluster-Based Distributed Controller Technology to Implement Failure-Tolerant Wide-Area Software-Defined Networking / Fujitsu Laboratories Ltd. Kawasaki, Japan, June 05, 2014.
7. Sherwood R. et. al. Carving research slices out of your production networks with open flow. SIGCOMM Comput. Commun. Rev., 40(1):129-130, January 2010.
8. Fernandes N.C.and O.C.M.B. Duarte. Xnetmon: A network monitor for securing virtual networks. In Communications (ICC), 2011 IEEE International Conference, p. 1-5, June 2011.
9. Drutskoy D., Keller E., and Rexford J. Scalable network virtualization in software-defined networks. Internet Computing, IEEE, 17(2):20-27, March 2013.
10. Chiosi M. Network Functions Virtualization: Network Operator Perspectives on Industry Progress / M. Chiosi, D. Clarke, C. Donley, et al. // Proceedings of SDN and OpenFlow World Congress, 15-17 October 2013, Frankfurt, Germany. Frankfurt, 2013. P. 1-16.
11. Ye K., Jiang X., Huang D. Live Migration of Multiple Virtual Machines with Resource Reservation in Cloud computing // IEEE International Symposium, 2013. pp. 267-274.
12. Pahl C., Xiong H. Migration to PaaS clouds - Migration process and architectural concerns - IEEE International Symposium, 2013. pp.86-91.
13Jinkyu J. Sung-Hun K., Hwanju K. Analysis of virtual machine live-migration as a method for power-capping. // The Journal of Supercomputing. 2013. Vol. 66, no 3. pp. 1629-1655.
Надшшла до редколеги 09.09.2016 Рецензент: д-р техн. наук, проф. Бараншк В.В.
Скулиш Марiя Анатолпвна, канд. техн. наук, доцент кафедри iнформацiйно-телекомунiкацiйних мереж Нащонального технiчного ушверситету Украши «Кшвський полiтехнiчний шститут iменi 1горя Окор-ського». Науковi iнтереси: безпека в телекомушка-цiйних системах, системи тарифшацп в телекомушка-цiйних компаниях, застосування ввдомих математич-них методiв в телекомунiкацiях, дослiдження параме-трiв якостi обслуговування в мобiльних мережах 5-го поколшня. Адреса: Украша, 03058, Кшв, пр. 1ндустрь альний, 2, тел. +38-050-607-42-29.
Skulish Maria Anatolievna, PhD, associate professor, Department of Information and Telecommunication networks, National Technical University of Ukraine "Kyiv Polytechnic Institute name dafter IgorSikorsky". Scientific interests: security in telecommunication systems, charging systems in telecommunication companies, application of known mathematical methods in telecommunications, research of service quality parameters in mobile networks of the 5th generation. Address: 2, Industrial Avenue, Kyiv, 03058, Ukraine, tel. + 38-050-607-42-29.
