Дослідження умов переходу на SDN-архітектуру мережі провайдера "Оріон" м. Сніжне

Вступ

Вимога до сучасних мереж підвищуються, і разом з цим, з величезною швидкістю розвиваються різні способи вирішення таких завдань, як забезпечення високого рівня масштабованості із забезпеченням необхідної якості обслуговування (Quality of Service, QoS). При цьому прагнуть до зниження вартості мережевої інфраструктури і витрат на її утримання.

Аналіз теперешнього стану проблеми

Головна проблема більшості мереж в тому, що набір засобів по забезпеченню QoS спочатку закладений виробниками в мережеві пристрої. Це, в свою чергу, не відповідає швидкості впровадження послуг і нових додатків в існуючі мережі передачі даних. Існуючі мережеві протоколи канального рівня, призначені для розширення можливостей мережевої інфраструктури Fiber Channel, Infiniband, а також EthernetII, мають обмежені можливості по управлінню трафіком і QoS. Вдосконалені варіанти протоколу Ethernet - Converged Enhanced Ethernet і Cisco Data Center Ethernet включають розширення з управління потоками на основі пріоритетів, поділу пропускної здатності, управління перевантаженнями і логічним станом трактів передачі даних, щодо забезпечення передачі без втрат, а також з одночасного використання декількох паралельних шляхів передачі даних між вузлами. Основні недоліки даних рішень - складна децентралізована схема управління потоками даних, заснована на безлічі закритих протоколів, значна вартість мережевого устаткування, складність його розширення. Окремо слід зауважити, що дані рішення використовують реактивну схему управління потоками, коли рішення по комутації приймаються під час передачі потоку.

Одним з рішень є використання архітектури програмно-конфігуруємих мереж (Software-defined Networking, SDN). Централізація і відкритість засобів управління SDN дозволяє гнучко і ефективно адаптувати роботу ЦОД під виникающі потреби бізнесу, що прискорює впровадження інновацій та забезпечує конкурентоспроможність компаній. Наявність потреби компаній у створенні ефективних розподілених обчислювальних ЦОД, що включають мережі зберігання даних, на основі SDN, перспективний характер технології SDN, а також відсутність готових рішень в цій галузі є суттєвими факторами що визначають актуальність цього напряму. Концепція програмно конфігуруються мереж (SDN) покликана змінити уявлення і суттєво вплинути на підхід до побудови мереж зв'язку. Комплексний підхід до перегляду основ побудови мереж, звичайно, почав привертати увагу компаній постачальників послуг саме тому, що вони бачать в найближчій перспективі, а деякі вже стикаються, з проблемами, які існуючими засобами вирішити, якщо і можливо, то дуже складно і невигідно. Інтернет провайдер, маючи сьогодні мережу, поки ще відповідну його потребам, стикається з проблемою значного щорічного зростання обсягів трафіку. В таких умовах він змушений постійно збільшувати свої витрати, тоді як доходи, які майже повністю залежать від середнього доходу на одного абонента, не можна постійно збільшувати відповідно до існуючих витрат, тому що, по-перше, це може стати причиною відтоку клієнтів, для яких дуже важливим аспектом є стабільність ціни за послуги; по-друге, навіть якщо ціна буде рости високими темпами, це неминуче призведе до ситуації, коли її підвищення буде вже неможливим через неплатоспроможність населення, яке може виділяти зі свого сімейного бюджету тільки якусь незначну частину коштів на послуги інтернет провайдера.

Для великих мереж провайдерів проблемою залишається швидкість відновлення мережі після впровадження і настройки нового пристрою. Наприклад, при запуску нового пристрою, наприклад перенастроювання списків доступу (Access Control List, ACL) на всіх мережевих пристроях мережі може зайняти чималий термін. Це відбувається через розподіленість управління. В результаті адміністраторам доводиться витрачати масу часу на те, щоб переналаштувати правила обробки трафіку на кожному мережевому пристрої. Аналогічні проблеми виникають, якщо необхідно переналаштувати QoS- механізми при впровадженні нової програми, наприклад відеозв'язку. Аналогічні проблеми виникають при необхідності змінити параметри захисту. Останнє може послабити загальну захищеність мережі.

Перехід на централізоване управління мережею, реалізоване в програмно-конфігуруються мережах дозволить послабити перераховані вище недоліки. Основною відмінністю SDN від мереж передачі даних є централізоване інтелектуальне управління і моніторинг мережі, які забезпечує перевірку, контроль і модифікацію потоків переданих даних. Згідно з концепцією SDN, вся логіка управління виноситься в спеціалізовані контролери, які здатні відслідковувати роботу всієї мережі (Рисунок 1).

Рисунок 1 – Компоненти SDN-архітектури

Мета та задачі роботи

Метою роботи є вироблення рекомендацій щодо впровадження SDN-архітектури в діючу мережу. Для досягнення поставленої мети необхідно проаналізувати можливість переходу до такої структури.

В ході дослідження необхідно вирішити наступні завдання:
• проаналізувати проблеми впровадження SDN-рішень в мережу інтернет провайдера;
• розробити рекомендації щодо еволюційного впровадження SDN-рішень в транспортну мережу;
• розробити методику оцінки параметрів економічної ефективності використання SDN-рішень інтернет провайдером;
• запропонувати засоби ефективного управління мультисервисного трафіку транспортної SDN мережі;
• розробити імітаційну модель, яка дозволяє оцінити працездатність і ефективність запропонованих рішень.

Аналіз доцільності впровадження SDN рішень в мережу провайдера

Прoграммнo-кoнфігуруєма мережа (SDN від англ. Software-defined Networking, також программнo-визначаєма мережа [1-5]) - мережа передачі даних, в якій рівень управління мережею реалізується прoграммно і прoстранственно рознесений з приладом передачі. Дана архітектура виникла, через неoбходність поділу функцій передачі трафікa і функцій упрaвління. Це зв’язaно, в першу чергу з «обмеженням» функціонaла алгoритмів управління трафікoм в існуючих мережевих приладах. Тобто постачальники мережевого устаткування по суті справи надають певний набір таких функцій. У додаванні до цього, процеси передачі трафіку, а також процеси управління трафіком реалізуються в єдиному пристрої (мікросхемі). Т.ч. забезпечується пересилання пакетів з одного порту на інший на основі правил, визначених програмним забезпеченням пристрою (аналіз пакетів, виробляє зміну службової інформації, що міститься в них і т. д.).

Концепція SDN дозволяє конфігурувати мережу як єдину систему, незалежну від виробника обладнання. Що досягається шляхом створення уніфікованого інтерфейсу між рівнем управління і рівнем передачі даних. Елементами SDN-архітектури є: додатки SDN, SDN контрoллер, упрaвляющі агенти, функції яких закладені в OpenFlow коммутатoри, FlowVisor або інтерфейс, oтвечающій за передачу упрaвляющей інформації, компoненти керування й адміністрірoванія.

Додатки SDN надають кінцевим користувачам необхідні сервіси. Однак вони містять ряд вимог до мережевої інфраструктури.

Контролер [6-10] є єдиною централізованою точкою управління. Він взаємодіє з рівнем додатків за допомогою відкритого інтерфейсу API, а також виконує функції контролю за фізичними пристроями. Використання контролера як єдиної точки управління дає можливість значно спростити логіку роботи і витрати на обладнання архітектури SDN, так як зникає необхідність у підтримці та обробці набору протоколів управління на транспортному рівні.

OpenFlow комутатори [11-15] відповідальні за взаємодію мережевої інфраструктури з рівнем управління. У них міститися одна або кілька таблиць переадресації (flowtable), в яких знаходяться всі дані про потоках інформації, що передається.

Рисунок 2 – Приклад таблиці потоків OpenFlow (7 кадрів, нескінченний цикл, 138 кб)

FlowVisor [16,17,27] забезпечує розподіл керуючої інформації між потоками даних. Він визначає безлічі потоків, які відносяться до тієї чи іншої підмережі. Також, в його функції входить забезпечення віртуалізації потоків керуючих пакетів в окремі зрізи мережі.

Компоненти управління і адміністрування - це набір статичних даних, що включають в себе зовнішні завдання: координацію політик і правил, прийнятих при проектуванні моделі архітектури SDN, початкові налаштування обладнання та правила розподілу мережевих ресурсів.

Основою управління SDN є протокол OpenFlow, який відстежує зміни на рівні передачі даних і заносить їх в таблицю переадресації, а також модифікує і пересилає керуючу інформацію між контролером і комутаторами. Протокол OpenFlow контролює обмін повідомленнями про зміни таблиць переадресації, підтримуючи при цьому стандартний набір параметрів.

Принцип роботы протокола OpenFlow

Вироблення рекомендацій по модернізації мережі

Контролер являє собою сервер, на якому встановлено відповідне програмне забезпечення. Відносини між ним і комутаторами з підтримкою OpenFlow дуже схожі на відносини типу «клієнт-сервер», де сервер (контролер) виносить рішення, а клієнт (комутатор) повинен втілювати ці рішення в життя. Тому, необхідно вирішити скільки контролерів потрібно для мережі і вони повинні бути розташовані. У загальному випадку мережа буде мати вигляд зірки - тобто один контролер, підключений до всіх елементів мережі. Однак є можливість, в залежності від кількості вузлів і їх розташування, використовувати кілька контролерів, які будуть створювати кілька SDN доменів.

Одним із основних факторів як у розташуванні контролеру, так і в виборі їх кількості для великого інтернет провайдера, є затримки відповідей контролеру [18-20] на запити елементів мережі. Дуже важливо мати швидку динамічну реакцію на події. Для вирішення цієї проблеми, знаючи розташування вузлів мережі та відстані між вузлами, пропонується методика для визначення місця розташування контролеру.

Припустимо, що є маємо граф G(V,E), де V-кількість вузлів, Е-кількість з’єднань. Позначимо d(r,s) – найкоротший шлях від вузла r V до s V, отримаємо:

Де Lср(R) – середня затримка при розташуванні контролеру у r V. Порівнявши таким чином середні затримки для кожного можливого r, знаходимо оптимальне розташування контролеру[4]. Якщо отримане оптимальне значення середньої затримки не задовільне, або через дуже велику кількість елементів мережі операційних можливостей сервера не вистачає, логічно було б використати декілька контролерів, розбивши перед цим нашу мережу G(V,E) на декілька G1(V1,E1)..Gn(Vn,En) за принципом топологічної близькості вузлів мережі, та застосувати до кожної підмножини запропоновану методику. Звичайно, у такому разі контролери мають бути пов’язані один з одним. Їх взаємодія має бути основана на тому, що кожен контролер має здійснювати зв’язок із сусідніми через спеціально виділений канал зв’язку. Це досягається шляхом встановлення додатку на контролер, для якого взаємодія контролер-контролер перетворюється на різновид контролер – комутатор.

Одним з недоліків централізації управління є менша відмовостійкість мережі [21-26] : при виході з ладу керуючого елемента або втрати зв'язку з ним «дурний» периферійний вузол може стати абсолютно марним, в той час як при самоврядуванні він легко адаптувався до ситуації, що змінилася.

Щоб підвищити надійність мережі, пропонується робити резервування контролерів. Для цього використовуємо FlowVisor – спеціальний OpenFlow контролер, який виступає в якості прозорого проксі між OpenFlow комутаторами та декількома OpenFlow контролерами. Він створює «зрізи» мережевих ресурсів та делегую контроль над кожним зрізом різним контролерам. Таким чином є можливість мати два контролери, що фізично приєднані до одних і тих же комутаторів, але які «бачать» та контролюють лише частину з них, а у разі відмови одного контролеру автоматично беруть на себе контроль над усіма підключеними до себе комутаторами. Це вирішує як проблему резервування контролерів, так і проблему простою.

Розуміючи практичну складність різкого переходу на нові рішення, пропонується наступний алгоритм переходу до SDN, який складається з трьох етапів.

Маючи встановлений SDN - контролер, перш за все необхідно провести послідовну заміну граничних маршрутизаторів. Одночасно їх замінити не можна тому, що вони задіяні в роботі мережі та передачі трафіку – це призведе до зупинки роботи усієї мережі. Таким чином, можливо від’єднати один з маршрутизаторів, замінити його на OpenFlow комутатор, підключений до контролеру. Є також можливість поставити OpenFlow комутатор у паралель до граничного маршрутизатора та перекинути з’єднання поступово. Для мережі все виглядає так, якби взагалі не сталося жодних змін, бо контролер просто візьме на себе ті ж самі функції контролю, які були до цього у маршрутизатора. Маючи повністю замінені граничні комутатори отримаємо майже SDN мережу, бо тепер контролер може визначати маршрут слідування трафіку. Але ця мережа не є повністю SDN мережею, бо вона не динамічно реагує на процеси, що в ній проходять - контролер отримує оперативну інформацію лише про ті з’єднання, які безпосередньо підключені до SDN комутатору.

Щоб повністю перейти до SDN усі елементи мережі мають підтримувати OpenFlow та бути підключені до контролеру. Було запропоновано методику знаходження основних вузлів [28,29], заміна яких дасть найбільший ефект, з точки зору ефективності керування мережею. Ідея полягає у тому, щоб кожен шлях в мережі походив хоча б через один транзитний SDN - комутатор. Якщо на першому етапі граничний SDN комутатор будував шлях через усю мережу до іншого граничного комутатора, то тепер він буде будувати шлях лише до ключового SDN комутатора. Це дозволить логічно спростити будь - який шлях та мати можливість більш оперативно реагувати на зміни в мережі. Далі наведена методика, яка полягає в знаходженні транзитних вузлів, які треба замінювати в першу чергу.

Позначимо l_ij – бінарну змінну, яка приймає значення 1, якщо у мережі існує лінк між вузлами i та j, та x_ij^st – бінарну змінну, яка дорівнює 1, якщо з’єднання між i та j лежить на шляху p_n(s,t), де s та t– наші граничні маршрутизатори. Змінна y_i приймає значення 1, якщо роутер і має бути замінений, u_i^st=1, якщо шлях проходить через SDN-комутатор. V-множина, до складу якої входять маршрутизатори з хмари. Математична модель знаходження ключових вузлів складається з рівнянь:

Вираз (2) означає, що мають бути використані лише існуючі шляхи. Вираз (3) – заповнюється квадратна матриця a[n][n]. Рівняння (4) ставить вимогу до того, що кожен шлях від одного Edge –s до іншого – t має включати хоча б один SDN-комутатор. Рівняння (5) вказує на те, що елемент мережі і було обрано для заміни. Вираз (6) підраховує кількість лінків d, які безпосередньо приєднані до маршрутизатора s. Таким чином, розраховується m – загальна кількість усіх можливих шляхів від s до t. Далі у (7) формується матриця k з кількістю рядків, що дорівнює кількості шляхів, та кількістю стовпців, рівною кількості елементів мережі. Формула (8) вказує на необхідність мінімізувати кількість маршрутизаторів, які потребують зміни, обов’язково зважаючи на умову (5).

Поступово замінивши усі маршрутизатори на SDN – комутатори, отримуємо повноцінну SDN мережу.

Висновок

На даному етапі написання магістерської роботи був сформований ряд рекомендацій щодо впровадження SDN-архітектури в функціонуючу мережу інтернет провайдера. В ході подальшого дослідження буде проведено моделювання нової SDN-структури на прикладі інтернет провайдера «Оріон» м. Сніжне і буде виконана оцінка економічної ефективності.

Передбачається, щo після завершального етапу SDN-архітектурa буде володіти підвищеною прoдуктивністю (стaбільнa робoтa запеспечується навіть при 100-процентному завантаженні каналів), можливістю перестрoйки фізичної мережі без преривaння oбслуговування в віртуaльних мережах, підвищенням ступеня безпечності за рахунок повної ізоляції віртуальних мереж одна від одної, збільшенням надійності мережі завдяки самовідновленню і автоматичному перерозподілу потоків трафіку відповідно до правил.

Таким чином, перехід до SDN-архітектурі дозволить підвищити якість як управління потоками трафіку, так і мережею в цілому. З іншого боку це рішення дозволить здешевити модернізацію існуючої мережі провайдера «Оріон» м. Сніжне, що поліпшить якість послуг при їх незмінній вартості.

Перелік посилань

1. SDN Architecture Overview [Электронный ресурс]. – Режим доступа: www.opennetworking.org.
2. Software defined networking [Электронный ресурс]. – Режим доступа: inau.ua.
3. Центры обработки данных. SDN: «третий элемент» для будущих дата-центров [Электронный ресурс]. – Режим доступа: www.sib.com.ua.
4. Introduction to Software Defined Networking (SDN)[Электронный ресурс]. – Режим доступа: www.cse.wustl.edu.
5. Open Networking:Dell’s Point of View on SDN [Электронный ресурс]. – Режим доступа: i.dell.com.
6. What's Software Defined Networking? [Электронный ресурс]. – Режим доступа: twiki.di.uniroma1.it.
7. SDN-NFV Reference Architecture [Электронный ресурс]. – Режим доступа: innovation.verizon.com.
8. Software Defined Networking (SDN) - Open Flow [Электронный ресурс]. – Режим доступа: www.ics.uci.edu.
9. Программируемый Интернет [Электронный ресурс]. – Режим доступа: www.ripn.net.
10. Software Defined Networking (SDN) and OpenStack [Электронный ресурс]. – Режим доступа: f5.com.
11. Oracle SDN Performance Acceleration with Software-Defined Networking [Электронный ресурс]. – Режим доступа: www.oracle.com.
12. SDN for Service Providers [Электронный ресурс]. – Режим доступа: www.cisco.com.
13. Software Defined Networking Concepts [Электронный ресурс]. – Режим доступа: homepages.inf.ed.ac.uk.
14. Software Defined Networking [Электронный ресурс]. – Режим доступа: www.comp.nus.edu.sg.
15. SDN Software Defined Networks [Электронный ресурс]. – Режим доступа: www.control.lth.se.
16. О.Ю. Евсеева, Е.Н. Иьяшенко, Е.Б. Ткачева Математическая модель и метод комплексного управления ресурсами транспортной программно-конфигурируемой сети // Электронное научное специализированное издание – журнал «Проблемы телекоммуникаций» №1(18) 2016 .
17. Красотин А.А., Алексеев И.В. Программно-конфигурируемые сети как этап эволюции сетевых технологий // Модель и анализ информ. систем. №4 2013.
18. Ю. Ю. Коляденко, Е. Э. Белоусова ПРОГРАММНО-КОНФИГУРИРУЕМЫЕ СЕТИ НА БАЗЕ ПРОТОКОЛА OPENFLOW И ИХ ХАРАКТЕРИСТИКИ // Scientific Journal «ScienceRise» №3/2(20)2016.
19. Н.Ф. Бахарева, Ю. А. Ушаков, М. В. Ушакова, А.Е. Шухман ОСНОВЫ ПРОГРАММНО-КОНФИГУРИРУЕМЫХ СЕТЕЙ // Учебное пособие.
20. Боклагов В.С., Лозинская В.Н. ИССЛЕДОВАНИЕ УСЛОВИЙ ПЕРЕХОДА НА SDN-АРХИТЕКТУРУ СЕТИ ПРОВАЙДЕРА «ОРИОН» Г. СНЕЖНОЕ // Автоматизация технологических объектов и процессов. Поиск молодых : сборник научных трудов ХVII научно-технической конференции аспирантов и студентов в г. Донецке 24-25 мая 2017 г. - Донецк : ДОННТУ, 2017. – 409 с..
21. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2013–2018: Cisco® February 5, 2014 [Електронний ресурс].
22. The Road to SDN: An Intellectual History of Programmable Networks: Nick Feamster, Jennifer Rexford, Ellen Zegura [Електронний ресурс].
23. OpenVirteX – A Network Hypervisor : Open Networking Lab [Електронний ресурс].
24. The Controller Placement Problem: Brandon Heller, Rob Sherwood, Nick McKeown [Електронний ресурс].
25. OpenFlow Switch Specication: Open Networking Foundation June 25, 2012 [Електронний ресурс].
26. DISCO: Distributed Multi-domain SDN Controllers: Kevin Phemius, Mathieu Bouet and Jeremie Leguay [Електронний ресурс].
27. FlowVisor: A Network Virtualization Layer: Deutsche Telekom Inc. R&D Lab, y Stanford University, _ Nicira Networks October 14, 2009 /Rob Sherwood, Glen Gibb, Kok-Kiong Yap [Електронний ресурс].
28. Analysis of CAPEX and OPEX Benefits of Wireless Access Virtualization: the 4th Workshop on E2Nets, Budapest, Hungary, June 9, 2013 / M.M.Rahman, Charles Despins. [Електронний ресурс].
29. Е.В. Дуравкин, Е.Б. Ткачева, Иссам Саад АРХИТЕКТУРА SDN. АНАЛИЗ ОСНОВНЫХ ПРОБЛЕМ НА ПУТИ РАЗВИТИЯ // Системи обробки інформації, 2015, випуск 3 (128).