Програмно-апаратна ідилія, або openflow, журнал мережевих рішень

Надіслати заявку на отримання матеріалів

Комп'ютери та мережеве обладнання довгий час існували незалежно. Комутатори передавали дані, комп'ютери їх обробляли. Зрозуміло, були і спроби до об'єднання - в основному з боку відкритих платформ. Так, наприклад, були створені програмні маршрутизатори, комутатори, мости і мережеві операційні системи. На жаль, внаслідок обмежених можливостей універсальних процесорів обчислювальна потужність програмних пристроїв була, як правило, недостатня для високопродуктивних додатків. На передньому краї мережевих технологій бал правили спеціалізовані мікросхеми - ASIC, нестандартні протоколи і операційні системи.

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

ЧАС ЗМІН?

Ключові мережеві протоколи були розроблені на зорі Інтернету і Ethernet, коли неможливо було навіть уявити сучасні швидкості і обсяги переданих даних. Якби сьогодні існувала можливість розробити їх з чистого аркуша і з урахуванням всього накопиченого досвіду, швидше за все, вони виявилися б абсолютно іншими.

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

Ситуація, що склалася перестала влаштовувати дослідників Стенфордського університету шість років тому. Їхні претензії були направлені на святая святих будь-якого комутатора Ethernet - таблиці комутації. Саме їм більшість таких пристроїв зобов'язані високими характеристиками по швидкості просування, передачі і фільтрації даних. Якби у комутаторів вдалося перехопити управління цими таблицями, то можна було б довільним чином управляти поведінкою і швидкісними характеристиками і окремого комутатора, і параметрами переданих потоків даних в масштабах всієї мережі Ethernet.

Винос ИНТЕЛЛЕКТА

Малюнок 1. Обробка та просування даних в комутаторі.

У звичайному комутаторі Ethernet одночасно реалізуються і рівень управління, і рівень передачі даних. Рівень управління представлений вбудованим мікроконтролером, рівень передачі даних - таблицею комутації і комутаційної матрицею (див. Малюнок 2). Володіючи деякими інтелектуальними функціями, мікроконтролер сам приймає рішення про просування кадрів на основі зібраної ним інформації про структуру мережі, яка часто має лише віддалене відношення до справжньої топології мережі (карта не є територією). Безпосередньо керувати прийняттям рішень не можна - можна лише конфігурувати мікроконтролер, задаючи певні набори правил і пріоритетів. Це накладає помітні обмеження на функціональність комутатора і всієї мережі. Зокрема, для організації зв'язків «кожен з кожним» в такій мережі не обійтися без комутаторів третього рівня - маршрутизаторів (див. Малюнок 2).

Малюнок 2. Функціональна схема традиційного комутатора Ethernet і мережі «кожен з кожним»: без маршрутизаторів не обійтися.

Центральний контролер має точну інформацію про структуру і топології мережі. Це дозволяє оптимізувати просування кадрів і, зокрема, прокладати зв'язку «кожен з кожним» на рівні L2, не вдаючись до IP-маршрутизації (див. Малюнок 3), і, крім того, попередньо «коммутировать» канали передачі даних на всьому шляху від джерела до пункту призначення. В результаті по мережі передаються вже не окремі кадри, а потоки даних.

Малюнок 3. Комутатор OpenFlow використовує для заповнення таблиць потоків центральний контролер мережі. Знання топології дозволяє будувати мережі «кожен з кожним» на рівні L2.

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

На жаль, життя набагато складніше, ніж ми її собі уявляємо. OpenFlow, по суті, є протоколом нижнього рівня, «асемблером» для програмування комутаторів. Програмне забезпечення для мереж SDN сьогодні лише на самому початку свого розвитку, в більшості випадків його тільки належить розробити, переконатися в правильності і масштабованості застосовуваних підходів.

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

Таблиці потоків, об'єднані в деревовидні структури, які розширюють можливості Вашого асоціативну пам'ять TCAM і реалізувати практично будь-які сценарії обробки і просування даних. Підтримка ECMP допомагає засобами OpenFlow, на другому рівні моделі OSI, вирішити завдання, за які традиційно відповідають комутатори третього рівня. Підтримка міток MPLS - емулювати обробку протоколів MPLS на діючому (і відносно недорогому) обладнанні програмними засобами.

ЗАСТОСУВАННЯ В ЦОД ...

Сучасні центри обробки даних можуть об'єднувати десятки тисяч фізичних серверів і сотні тисяч віртуальних машин. В силу вступає економіка масштабів - чим більше число серверів, тим менше капітальні витрати з розрахунку на сервер і, при належній автоматизації процесів, оперативні витрати. Разом з тим це створює певні проблеми при побудові мереж ЦОД. Для більшості клієнтів оптимальна зв'язність на рівні L2, однак при традиційних підходах до побудови мереж Ethernet розміри мережевих сегментів, як правило, обмежуються кількома тисячами пристроїв, а при подальшому масштабування виникають серйозні проблеми.

Мережі IP можуть бути будь-якого розміру, але накладають певні обмеження на переміщення віртуальних і реальних машин між підмережами IP. Пропускна здатність мереж Ethernet в традиційній архітектурі доступ / агрегація / ядро ​​теж далека від максимально реалізуються значень і вимог вирішуваних завдань. Як результат, все більшої популярності набувають розподілені комутаційні матриці (Fabric), зменшення числа рівнів агрегації трафіку і комірчасті мережеві структури (Mesh). Рідкісний виробник мережевого устаткування для центрів обробки даних не пропонує сьогодні відповідних рішень. На жаль, як правило, вони не сумісні один з одним і обмежують для оператора ЦОД вибір постачальників мережевого устаткування. Масштаби сучасних центрів обробки даних ще більше ускладнюють такий вибір.

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

Потенційні переваги OpenFlow і програмованої мережевої інфраструктури для мереж ЦОД:

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

... І операторський МЕРЕЖАХ

Багатопротокольна маршрутизація. Ще один проект, SPARC, націлений на розробку і тестування мереж доступу MPLS, в яких протокол OpenFlow покликаний забезпечити поділ рівнів управління і просування даних і взаємодія з опорними мережами IP / MPLS. У реалізації підтримки MPLS активно брала участь і компанія Ericsson.

Бездротовий роумінг. В рамках проекту OpenRoads розробники Стенфордського університету, використовуючи ешелоновані мережі OpenFlow з комутаторів, точок доступу WiFi і базових станцій WiMAX, на практиці продемонстрували безшовний, без розриву з'єднання, роумінг між бездротовими мережами передачі даних різних стандартів.

Список можна продовжити ...

У ЗАЛОЗІ І ПІСКУ

В даний час підтримка протоколу OpenFlow 1.0 реалізована в комутаторах безлічі виробників - Extreme Networks, Cisco, Juniper, IBM, HP, NEC, Huawei і деяких інших. Як правило, підтримка реалізується програмно, заміною прошивки комутатора. Так, за заявами розробників HP Labs, комутатори серій HP E3500, E5400 zl і E6600 з підтримкою OpenFlow використовуються в проектах більше 30 організацій по всьому світу, представники компанії Extreme Networks повідомляють про успішне тестування комутаторів Extreme Networks Summit X460 і X480 в зв'язці з контролерами Стенфордського університету і комерційним контролером BigSwitch.

Як уже зазначалося, комутатори OpenFlow 1.0, включаючи комерційні, з технічною підтримкою, доступні вже зараз, в тому числі для мереж 40G Ethernet. Використання системи на кристалі Broadcom Trident BCM56840 і власної програмної архітектури відкритого комутатора (Open Switch Software Architecture, OSSA) дозволило компанії Pronto вивести на ринок дві моделі пристроїв OpenFlow для центрів обробки даних: Pronto 3980 з 16 портами 40 Гбіт / с і Pronto 3920 з 48 портами 10 Гбіт / с і чотирма 40 Гбіт / с. Обидва комутатора мають пропускну здатність 1,28 Тбіт / с при ціні трохи вище 10 тис. Доларів. Підтримка OpenFlow доступна і для мережевих процесорів Quanta LB4G, Broadcom 56634, Broadcom 56820 і т. Д.

Ще одна модель комутатора OpenFlow, на цей раз віртуального, увійшла до складу платформ віртуалізації XenServer 5.6 Feature Pack 1 і наступних версій. За заявами компанії Citrix, використання OpenFlow, поряд з іншими нововведеннями, реалізованими в віртуальних комутаторах Open vSwitch, забезпечує приріст продуктивності до 70%. Більш того, як заявляється, Open vSwitch може управляти і апаратними комутаторами Ethernet з підтримкою OpenFlow.

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

OPENFLOW ВУкаіни І В СВІТІ

Історія OpenFlow, поза всяким сумнівом, тільки починається. Будучи протоколом нижнього рівня, він потребує великої програмної надбудові, створенням якої займаються більше 70 компаній і університетів усього світу. На карті проектів відзначені США, Європа, Бразилія, Індія, Китай, Японія. Є навіть Африка ...

Немає лішьУкаіни - на схемах тут, принаймні поки, невинно чиста територія. Намагаючись знайти хоч якісь сліди OpenFlow, я буквально прошерстил український Інтернет, обдзвонив кількох своїх знайомих, в тому числі професійно займаються розробкою українських суперкомп'ютерів і експлуатацією комерційних ЦОД. Здавалося б, переваги OpenFlow в гнучкої організації детермінованих швидкісних каналів і побудові масштабних матричних структур зі зв'язками «кожен з кожним» могли б бути затребувані при об'єднанні системних блоків - складових елементів суперкомп'ютерів. Як з'ясувалося, для поточних завдань цілком вистачає можливостей, вже реалізованих комутаторами Ethernet і Infiniband. Оператори посилалися на невеликий розмір центрів обробки даних: масштабні хмарні проекти - попереду, а поки потреби замовників можна задовольнити за допомогою наявних технологій і ресурсів.

Extreemальний OpenFlow

Механізми і ідеї, закладені в технологію OpenFlow, дуже перспективні і обов'язково будуть затребувані ринком. Стимулом для попиту стануть насамперед економічні чинники: уніфіковані комутатори, що працюють із зовнішніми керуючими контролерами (без власної Control Plane), будуть коштувати значно менше, ніж повнофункціональні пристрої.

Extreme Networks постійно взаємодіє з університетами і бере участь в їх розробках і дослідженнях. У напрямку OpenFlow компанія тісно співпрацює не тільки з Стенфордським університетом, який став родоначальником цієї технології, але і ще з трьома - з Масачусетським, Ессекскій і Вашингтонським. Інтерес до OpenFlow спостерігається і з боку комерційних замовників.

Технологія OpenFlow може бути реалізована в двох типах комутаторів:

• OpenFlow-only switch реалізує тільки основні клієнтські функції протоколу OpenFlow;
• OpenFlow-capable switch підтримує основні клієнтські функції протоколу OpenFlow, а також стандартні функції комутаторів (STP, LAG і т. Д.).

Комутатори Extreme Networks відносяться до другого різновиду. Це дозволяє, з одного боку, зменшити їх вартість, а з іншого - дуже гнучко використовувати в уже існуючих інфраструктурах ЦОД і істотно спростити процес переходу на OpenFlow.

Першою компанією, яка наважилася на тестування і впровадження технології OpenFlow вУкаіни, стала «Крок», яка вже зараз впроваджує технологію OpenFlow в хмарної мережі, побудованої на основі мережевого обладнання Extreme Networks.

В даний момент проводиться тестування модуля OpenFlow для ExtremeXOS на комутаторах Extreme Networks Summit X460 і X650. Тестування проходить успішно і показує хороші результати. До початку наступного року ми плануємо випустити промисловий реліз ExtremeXOS з підтримкою OpenFlow. - Сергій Гусаков, технічний директор Extreme Networks Україна і СНД.

OpenFlow в хмарі «Крок»

В хмарі «Крок» OpenFlow застосовується для віртуалізації мережевої інфраструктури: ця послуга доступна замовникам в рамках пропозиції IaaS - віртуального центру обробки даних. Завдяки OpenFlow вони можуть розгортати і настроювати віртуальні мережі в режимі самообслуговування, причому мова йде про віртуальні мережах Ethernet на другому мережевому рівні - не про IP-віртуалізації. Внаслідок цього в нашу інфраструктуру можна перенести, в тому числі, екзотичні і застарілі додатки, де використовуються, скажімо, протоколи IPX.

Вирішення цього завдання традиційними методами було б пов'язано з певними складнощами. Наприклад, віртуальні локальні мережі, які знаходять широке застосування для розділення трафіку користувачів і додатків, підтримуються всіма виробниками апаратних мережевих засобів, але в одній мережі може бути не більше 4094 VLAN. Це хороший показник, але сам факт наявності такого обмеження, змушує будь-якого провайдера хмарних послуг зайнятися пошуком альтернативних рішень для управління потоками мережевого трафіку в хмарі.

Інший приклад - технологія MPLS. Оператори використовують її для об'єднання розподілених територіальних мереж, а «Крок» - при будівництві катастрофостійкої рішень, які об'єднують мережі двох центрів. Цим рішенням складно управляти ззовні, і для нас, як для провайдера хмарних послуг, дана обставина критично. Ми зацікавлені в автоматизованому, віртуалізувати підході до управління мережею, щоб її можна було передати замовнику для самостійної експлуатації. Якби нам довелося самим виконувати всі запити, це позначилося б на ефективності і вартості надання послуг.

Основна перевага OpenFlow - зняття перерахованих вище обмежень традиційних технологій. Повністю воно проявляється тільки при використанні засобів автоматизації управління, без яких самообслуговування неможливо. Але це вже наш секрет. - Руслан заедіно, керівник напрямку центрів обробки даних «Крок».

Але ж Україна, з її традиційно сильними програмістами і тим більше досвідом розробки суперкомп'ютерів, могла б практично на рівних брати участь в створенні як нового напряму, так і нового покоління мереж. Чекаємо-с?

Поділіться матеріалом з колегами і друзями