ІТ-інфраструктура для вашого підприємства
Програмно-конфігуровані мережі (Software Defined Networks, SDN) - одна з найбільш «гарячих» сьогодні технологій, які постали на шляху колапсу Мережі, однак, незважаючи на те що тема ще відносно нова, навколо неї вже сформувалося кілька полярних думок: від повного захвату до скепсису і кліше «маркетинговий бантик» 1.
Комп'ютерні мережі як основоположна інфраструктура - стратегічний фактор розвитку сучасних інформаційних технологій, однак архітектура Мережі, основи якої закладалися ще в кінці 60-х років, застаріла і вже не завжди здатна адекватно і ефективно реагувати на нові потреби. Зростання кількості і різноманітності мобільних пристроїв, розвиток різних технологій бездротового зв'язку призвели до того, що сьогодні число їх користувачів перевищило число користувачів мереж з фіксованим зв'язком. Однак зростання потужності мобільних терміналів стимулює збільшення обчислювальної ємності додатків, що, в свою чергу, вимагає збільшення пропускної спроможності каналів зв'язку - обсяг мобільного трафіку зростає в геометричній прогресії, а види трафіку стають все більш різноманітними. За даними провідних виробників мережевого устаткування, трафік подвоюється приблизно кожні дев'ять місяців, що в найближчі кілька років призведе до збільшення навантаження на кілька порядків. У той же час сьогодні ефективність доступного спектра частот для мобільних мереж вже близька до насичення.
Для того щоб впоратися зі значним ростом трафіку, бездротові мережі повинні мати більш щільне покриття, і якщо зробити соту невеликий, наблизивши мобільного клієнта до базової станції, то це збільшить пропускну здатність стільники і зменшить кількість користувачів в ній. За оцінкою експертів, для цього буде потрібно в 20 разів збільшити щільність розміщення базових станцій. Однак сучасна мережева архітектура погано пристосована для підтримки такого щільного трафіку. По-перше, неможливо рівномірно збільшити щільність покриття - базові станції доведеться розгортати всюди, де це можливо, тобто хаотично. По-друге, такою інфраструктурою буде дуже складно управляти, вона буде відчувати нерівномірні навантаження, взаємні впливи сот і дію інших факторів. По-третє, щільна інфраструктура дуже дорога в розгортанні і експлуатації.
Розвиток мікропроцесорної техніки і телекомунікацій призвело до того, що зараз на кожну людину припадає в середньому близько 40 чіпів, проте з'являються все нові мережеві пристрої, внесення будь-яких змін в їх існуючі конфігурації занадто багато роботи, затратно і практично неможливо без залучення виробника. Не можна гарантувати, що програмно-апаратні засоби виробника містять тільки ту функціональність, яка описана в документації, а в мережах ситуація може бути ще складніше - така функціональність може бути розподіленою. Засоби побудови мереж сьогодні пропрієтарних, їх основний функціонал реалізований апаратно і закритий для змін з боку власників мереж.
Одночасно з ростом кількісних показників навантаження на мережі ускладнилися завдання управління мережами - збільшилися їх перелік, значимість і критичність, причому на тлі підвищення вимог до безпеки і надійності. Мережі будуються на базі пристроїв, які постійно ускладнюються, оскільки змушені підтримувати все більше розподілених стандартних протоколів (сьогодні число активно використовуваних протоколів і їх версій перевищила 600), одночасно використовуючи закриті (пропрієтарні) інтерфейси. В таких умовах провайдери не можуть оперативно вводити нові сервіси, а виробники мережевого обладнання не можуть швидко модернізувати свої вироби для задоволення вимог замовників. Як наслідок, підтримка і управління складної мережевою інфраструктурою стали мистецтвом, а не інженерією, що частково підтверджується збільшенням числа мережевих атак, вірусів і інших мережевих погроз, які свідчать про те, що питання безпеки до сих пір не мають надійних рішень.
У 70-80-ті роки в СРСР велися роботи над своїми стандартами і засобами побудови мереж. Найчастіше вони були несумісні зі стандартами, що приймалися тим, що пізніше стало Інтернет Співтовариством (www.icos.org), зокрема, це призвело до того, що в країні не виникло свого виробництва мережевого обладнання. В результаті вітчизняні телекомунікаційні інфраструктури сьогодні будуються на основі зарубіжних засобів, а значить, управління інфокомунікаційних мережами в Росії можливо лише настільки, наскільки це дозволяють вироби зарубіжних виробників.
Отже, можна виділити наступні проблеми сучасних комп'ютерних мереж:
- науково-технічні - сьогодні неможливо контролювати і надійно передбачити поведінку таких складних об'єктів, як глобальні комп'ютерні мережі;
- економічні - мережі дороги, складні і вимагають для свого обслуговування висококваліфікованих фахівців;
- проблеми розвитку - в архітектурі сучасних мереж є істотні бар'єри для експериментування і створення нових сервісів.
Відповіддю на кризу комп'ютерних мереж стала поява принципово нового підходу до їх побудови - програмно-конфігуруються мереж.
Що таке SDN?
Зацікавленість ІТ-компаній в SDN викликана тим, що такі технології дозволяють підвищити ефективність мережевого обладнання на 25-30%, знизити на 30% витрати на експлуатацію мереж, перетворити управління мережами з мистецтва в інженерію, підвищити безпеку і надати користувачам можливість програмно створювати нові сервіси і оперативно завантажувати їх в мережеве обладнання.
У частині досліджень і розробок ключові заділи в SDN пов'язані з розвивається в США програмою GENI (Global Environment for Network Innovations) дослідження майбутнього Інтернету, яка об'єднує близько 40 провідних університетів США; діяльністю об'єднаного центру Стенфорда і Берклі (Open Network Research Center), що виконує дослідження і розробки в області Internet2; а також з Сьомої рамкової програми досліджень Європейського Союзу Ofelia і проектом FEDERICA.
Основні ідеї SDN:
- поділ процесів передачі та управління даними;
- єдиний, уніфікований, незалежний від постачальника інтерфейс між рівнем управління і рівнем передачі даних;
- логічно централізоване управління мережею, здійснюване за допомогою контролера з встановленої мережевою операційною системою і реалізованими поверх мережевими додатками;
- віртуалізація фізичних ресурсів мережі.
архітектура
В архітектурі SDN можна виділити три рівні (рис. 1):
- інфраструктурний рівень. надає набір мережевих пристроїв (комутаторів і каналів передачі даних);
- рівень управління. що включає в себе мережеву операційну систему, яка забезпечує додаткам мережеві сервіси та програмний інтерфейс для управління мережевими пристроями і мережею;
- рівень мережевих додатків для гнучкого й ефективного управління мережею.
Мал. 1. Архітектура програмно-конфігуруються мереж
Найбільш перспективним і активно розвиваються стандартом для SDN є OpenFlow (OpenFlow версія 1.3) - відкритий стандарт, в якому описуються вимоги, що пред'являються до комутатора, що підтримує протокол OpenFlow для віддаленого управління.
За допомогою сучасних маршрутизаторів зазвичай вирішуються дві основні задачі: передача даних (forwarding) - просування пакета від вхідного порту на певний вихідний порт і управління даними - обробка пакету і прийняття рішення про те, куди його передавати далі, на основі поточного стану маршрутизатора. Це відповідає рівню передачі даних, на якому зібрані кошти передачі (лінії зв'язку, каналоутворювального обладнання, маршрутизатори, комутатори), і рівнем управління станами засобів передачі даних (рис. 2). Розвиток маршрутизаторів досі йшло по шляху зближення цих рівнів, проте з ухилом на передачу (апаратне прискорення, вдосконалення ПО і впровадження нових функціональних можливостей для збільшення швидкості прийняття рішення по маршрутизації кожного пакета), тоді як рівень управління залишався досить примітивним і спирався на складні розподілені алгоритми маршрутизації і хитромудрі інструкції по конфігурації і налаштування мережі. Зрозуміло, ПО маршрутизаторів, що реалізує рівень управління, було пропрієтарним і закритим.
Мал. 2. Традиційні мережі і SDN
Згідно зі специфікацією 1.3 стандарту OpenFlow, взаємодія контролера з комутатором здійснюється за допомогою протоколу OpenFlow - кожен комутатор повинен містити одну або більше таблиць потоків (flow tables), групову таблицю (group table) і підтримувати канал (OpenFlow channel) для зв'язку з віддаленим контролером - сервером. Специфікація не регламентує архітектуру контролера і API для його додатків. Кожна таблиця потоків в комутаторі містить набір записів (flow entries) про потоках або правила. Кожна така запис складається з полів-ознак (match fields), лічильників (counters) і набору інструкцій (instructions).
Механізм роботи комутатора OpenFlow досить простий. У кожного пакету, що прийшов «вирізується» заголовок (бітова рядок певної довжини). Для цієї бітової рядки в таблицях потоків, починаючи з першої, шукається правило, у якого поле ознак найближче відповідає (збігається) заголовку пакета. При наявності збігу, над пакетом і його заголовком виконуються перетворення, які визначаються набором інструкцій, зазначених в знайденому правилі. Інструкції, асоційовані з кожним записом таблиці, описують дії, пов'язані з пересилкою пакета, модифікацією його заголовка, обробкою в таблиці груп, обробкою в конвеєрі і пересиланням пакета на певний порт комутатора. Інструкції конвеєра обробки дозволяють пересилати пакети в наступні таблиці для подальшої обробки і у вигляді метаданих передавати інформацію між таблицями. Інструкції також визначають правила модифікації лічильників, які можуть бути використані для збору різноманітної статистики.
Якщо потрібного правила в першій таблиці не виявлено, то пакет инкапсулируется і відправляється контролеру, який формує відповідне правило для пакетів даного типу і встановлює його на комутаторі (або на наборі керованих їм комутаторів), або пакет може бути скинутий (в залежності від конфігурації комутатора) .
Записи про потоках можуть також вказувати на групи, в яких визначається додаткова обробка. Групи є наборами дій для широкомовної розсилки, а також набори дій пересилання з більш складною семантикою, наприклад швидка зміна маршруту або агрегування каналів. Механізм груп дозволяє ефективно змінювати загальні вихідні дії для потоків. Таблиця груп містить записи про групи, що містять список контейнерів дій зі спеціальною семантикою, що залежить від типу групи. Дії в одному або декількох контейнерах дій застосовуються до пакетів, що відправляються в групу.
Управління даними в OpenFlow здійснюється не на рівні окремих пакетів, а на рівні їх потоків. Правило в комутаторі OpenFlow встановлюється за участю контролера тільки для першого пакету, а потім всі інші пакети потоку його використовують.
Наявні на сьогоднішній день фізичні комутатори SDN відповідають поки специфікації OpenFlow 1.0 і містять тільки одну таблицю потоків.
протокол OpenFlow
Ідея SDN про створення уніфікованого, незалежного від виробника мережевого устаткування, програмно-керованого інтерфейсу між контролером і транспортної середовищем мережі знайшла відображення в протоколі OpenFlow, що дозволяє користувачам самим визначати і контролювати, хто з ким, за яких умов і з якою якістю може взаємодіяти в Мережі . Протокол підтримує три типи повідомлень: контролер-комутатор, асинхронні і симетричні.
Повідомлення типу контролер-комутатор ініціюються контролером і використовуються для безпосереднього управління і стеження за станом комутатора. Повідомлення цього типу можуть використовуватися контролером для установки параметрів конфігурації комутатора, для збору статистики, для додавання, видалення і модифікації записів в таблицях потоків.
Асинхронні повідомлення ініціюються комутатором для оповіщення контролера про мережеві події (прибуття пакетів або видаленні запису з таблиці по тайм-ауту) і зміни стану комутатора або помилки.
Симетричні повідомлення можуть ініціюватися комутатором або контролером без запиту і використовуються при встановленні з'єднання, а також при вимірюванні затримок, пропускної здатності з'єднання контролер-комутатор або для перевірки живучості з'єднання.
мережева ОС
Логічно-централізоване управління даними в мережі передбачає винесення всіх функцій управління мережею на окремий фізичний сервер, званий контролером, який знаходиться у віданні адміністратора мережі. Контролер може керувати як одним, так і кількома OpenFlow-комутаторами і містить мережеву операційну систему, яка надає мережеві сервіси по низкорівневому управління мережею, сегментами мережі і станом мережевих елементів, а також додатки, які здійснюють високорівневе управління мережею і потоками даних.
Мережева ОС (СОС) забезпечує додаткам доступ до управління мережею і постійно відстежує конфігурацію засобів мережі. На відміну від традиційного тлумачення терміна ОС, під СОС розуміється програмна система, що забезпечує моніторинг, доступ і управління ресурсами всієї мережі, а не її конкретного вузла.
На даний момент є 28 реалізацій мережевих ОС для програмно-визначених мереж: NOX, POX, Beacon, Maestro, Trema, BigSwitch, FloodLight і ін.
Для контролерів в SDN дуже важливим є вимога того, що всі програми одного контролера в кожен момент часу повинні мати однакове уявлення про топологію мережі. Однак перехід від розподіленого управління мережею до централізованого має і ряд недоліків. Наприклад, зниження надійності, відмовостійкості, масштабованості.
Сьогодні отримали розвиток кілька підходів до побудови розподіленого масштабованого контролера: HyperFlow [3], Onix [4] і Kandoo [5]. Однак, згідно з результатами досліджень ЦПИ КС, найбільш перспективний альтернативний підхід (рис. 3). Оскільки кожен контролер може бути з'єднаний з декількома комутаторами, а кожен комутатор - з декількома контролерами, то контролери, що управляють одним і тим же комутатором, можна об'єднати в груповий контролер (ГК). Всі контролери одного і того ж ГК повинні мати узгоджену уявлення про топології тієї частини мережі, до якої вони забезпечують доступ. Як видно з рис. 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.
Мал. 3. Альтернативний підхід до побудови розподіленого масштабованого контролера