Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Технологія P4: чи стане вона майбутнім Software Defined Networking

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

Донедавна з цим справлявся SDN (Software Defined Networking), однак його потенціал був суттєво обмежений негнучкістю мережевого обладнання. Це і підштовхнуло networking-спільноту створити програмоване обладнання, яке б замінило традиційні світчі. В основу інновації лягла мова програмування P4.

У цій статті я розказую, чи стане P4 чарівною пігулкою для мережевої індустрії та в яких випадках вона точно спрацює.

Чому програмно-конфігурованим мережам (SDN) потрібен P4

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

Перш за все, кожен протокол повинен пройти через робочу групу IETF (Internet Engineering Task Force), що само по собі є тривалим процесом. Після того, як офіційний стандарт визначено, дизайнери чіпів мають імплементувати його у свої ASIC-и (реальні приклади, такі як VXLAN, показують, що ця частина може тривати навіть декілька років). До того ж, ніхто не гарантує, що жодні модифікації протоколів не знадобляться через якийсь час.

Мало того, що компанії, які оперують великими мережами, повинні чекати на обладнання, щоб підтримувати ці протоколи, є ще одна важлива проблема. Виробники мережевих чіпів — єдині, хто може визначити, як працюватиме та чи інша функція. Користувачі промислових мереж розуміють, що вони не можуть диктувати свої побажання, натомість змушені використовувати рішення, які їм нав’язують їхні вендори. Поява P4 — це результат об’єднаних зусиль консорціуму з розробки програмованих мережевих чіпів, який прагне перевернути цей підхід з ніг на голову, дозволяючи підприємствам встановлювати власну логіку обробки і пересилання пакетів мікроконтролерами.

Чому вашій мережі потрібен P4

P4 (Programming Protocol-Independent Packet Processors) — це предметно-орієнтована мова програмування для вираження того, як пакети обробляються через data plane програмованого елементу переадресації. Це може бути апаратний чи програмний комутатор, інтерфейсна мережева карта, роутер або інше мережеве обладнання.

P4 забезпечує розробнику базовий набір інструментів для впровадження мережевого стеку в апаратне забезпечення. Він здатен оперувати такими абстракціями, як типи заголовків (набір полів і їхні розміри), парсери (як заголовки організовані разом, як їх розрізнити тощо), таблиці для пов’язування ключів з діями, лічильники тощо. Але не більше. Мова P4 не знає, як виглядає Ethernet чи IP-заголовки. Саме девелопер тлумачить чіпу, що таке Ethernet-заголовок і як його розібрати, виконати порівняння, зібрати (збудувати заголовок для вихідних пакетів) і до якого порта (чи портів) передати пакет, тощо.

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

Чи замінить P4 OpenFlow

OpenFlow — це один з найпоширеніших сьогодні SDN-протоколів. Він має встановлену інфраструктуру, спільноти і контролери, що працюють поверх нього. Чого ще хотіти? Марно сподіватися, що всі відмовляться від OpenFlow і почнуть впроваджувати світчі за допомогою P4 у своїх мережах. Однак OpenFlow має декілька значних недоліків, які працівники дата-центрів повинні взяти до уваги.

Функції OpenFlow базуються на наборі визначених протокольних заголовків (також відомих під назвою TTPs — table type patterns), які вендори обладнання можуть підтримувати або ні. Більше того, додавання нового TTP не є завданням з легких і вимагає великої роботи, так само як і залучення спільноти. Це може не задовольняти вимоги академічного дослідження або динамічного середовища в дата-центрах, де вимоги змінюються дуже швидко або коли вони навіть невідомі. Натомість P4 дозволяє програмувати обладнання загальним способом і впроваджувати його за лічені дні.

Цікаво, що OpenFlow також може бути написаний мовою P4, що робить його, по суті, часткою того, що P4 може запропонувати світові. P4 — це незалежний від протоколу інструмент, який може імплементувати мережевий стек для будь-якої потреби і забезпечити контролеру API для заповнення таблиць. Проблема з OpenFlow в тому, що він вимагає перегляду специфікації, у той час як рішення, базовані на P4 (як наприклад, P4 Runtime), є гнучкішими і динамічнішими.

Інша річ, на яку варто звернути увагу, — це OF-DPA (OpenFlow data plane abstraction) — апаратна абстракція, яку розробила компанія Broadcom, щоб накладати OpenFlow-специфікацію на свій пайплайн. Чим більше OF-DPA буде адаптовано мережами, тим більше OpenFlow буде пов’язаний з бродкомівськими чіпами. OpenFlow не виправдовує первинне покликання SDN бути незалежним від вендорів. Інші компанії мають іншу пайплайн-імплементацію і не зможуть слідувати OF-DPA специфікації, шукаючи інші можливості, такі як P4, де вони все ще залишаються конкурентноздатними.

Приклади використання P4

P4 Runtime. P4 Runtime завойовує все більше і більше популярності у світі SDN-контролерів, whitebox-рішень тощо. Призначення цього проекту полягає в наданні автогенерованого інтерфейсу для програмування P4 таблиць. Він, як і P4, повністю незалежний від протоколів і вендорів.

Один із актуальних проектів з використанням P4 — це ONOS. Проект спрямований на підтримку P4 Runtime як протоколу для контролю P4 пайплайнів і роботи з match-action таблицями через існуючі ONOS API. ONOS вже підтримує пристрої, що базуються на Tofino і Spectrum на чолі з P4 Runtime API.

Stratum — це оупенсорсний проект Google для розробки референсної реалізації white-box світчів. Ця платформа також використовує P4 як інструмент за власним вибором для визначення пайплайну мережевого чіпа разом з P4 Runtime для динамічного програмування таблиць.

Inband Network Telemetry. INT — це інфраструктура, призначена для збору і звітування стану мережі засобами самих мережевих чіпів, без перевантажування контролера. INT є реальним кандидатом для того, щоб бути реалізованим на P4, тому що він може змінюватися з часом і вимагати додаткових розширень функціоналу. P4 пропонує абсолютно гнучкий підхід, що дозволяє відслідковувати теоретично будь-які атрибути мережі. Користувачі самі можуть вирішити, які дані повинні бути додані в заголовок і які вузли повинні це робити. Використовуючи цей підхід, можна відслідковувати шлях пакету в мережі, затримку при передаванні, заповнення буферів пам’яті і багато інших метрик.

Behavioral Model. Мова програмування P4 може використовуватися як «золотий стандарт» для індустрії, щоб пояснювати вендорам обладнання, як повинні поводитися їхні мікроконтролери. Програмний світч P4 дозволяє компілювати і запускати симуляції, написані на P4, щоб розробляти новий функціонал без жодного обладнання для обробки пакетів.

SAI. Передбачалося, що P4 буде використовуватися не лише для визначення пайплайну з нуля, але й для того, щоб розширити існуючий. Як приклад, Microsoft і Mellanox продемонстрували розширення для оупенсорсного NOS SONiC. SONiC використовує SAI (Switch Abstraction Interface) у якості відкритого API, якого повинні дотримуватися вендори. Оскільки P4 не зважає на те, який тип API генерує компілятор, він також може генерувати (або розширювати) вже існуючі API, такі як SAI. Це приносить багато вигоди для бізнесів, чиї мережеві вимоги задовольняються старішими протоколами, але які все ж потребують розширення функціоналу для спеціальних випадків. Як і в ситуації із заголовками SAI, новий модуль може бути доданий до ASIC через P4 і сконфігурований через SAI-розширення.

Яке майбутнє у P4

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

Потенційно така гнучкість може привести до економії коштів і дозволить компаніям купувати мережеве обладнання напряму у виробників, без посередництва. У свою чергу постачальники чіпів не хочуть прогавити нагоду і інвестують у підтримку P4, щоб залишатися у грі. Навіть якщо сьогодні ще невідомо достеменно, чи P4 стане стандартом для індустрії, ініціативи таких компаній, як Google, Microsoft та інших, сприяють тому, щоб це сталося.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




14 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

На картинке правильно было бы написать вместо «OpenFlow Controller» — «SDN controller»
т.к. протокол «под» контроллером может быть какой угодно вплоть до SNMP.
Насколько я знаю, основная проблема опенфлоу — это высокая стоимость поддерживающего (на уровне асиков) оборудования, т.к. его детальные правила занимают много места в ТСАМ. Что тут может предложить Р4?

основная проблема его на данный момент — негибкость+он не дает полного контроля над коммутатором, Р4 — дает
Собственно
p4.org/...​ween-p4-and-openflow.html

достаточно хорошо это описывает
Плюс основная идея Р4 — ввести полный контроль над работой свитчинга и изменять ее по принципу CI/CD — в принципе достаточно интересна , опенфлоу этой возможности в полной мере НЯП не представляет (хотя могу ошибаться)

Я вже трохи смутно пам’ятаю, але це не контролер не дає повного контролю над мережевим обладнанням, а виробники обладнання його не дають. І не дадуть. А чого?
Тому навіть google, коли в нього стали задачі, які вирішуються SDN, створив не тільки свій власний SDN B4, а і свій власний маршрутизатор для нього. Без цього обмеження і контролер Openflow відмінно справляється з управлінням, правда тільки з open vswitch, і тільки TCP/IP.

Саме так, виробник і не дає, оскільки він зашиває у ейсіку алгоритм роботи комутатора. Повного-найповнішого контролю у вас ніколи не буде, буде можливість за допомогою Р4 програмувати поведінку мережевого обладнання 2 та 3 рівня. Це раз.
Два — ви трохи помиляєтеся , коли приводите приклад гугла. По-перше , у статті йде обговорення мережевого пристрою 2 рівня, а маршрутизатор — це вже 3 рівень і там логіка роботи вже давно керується за допомогою SDN й її легше впроваджувати, оскільки де-факто масово існує лише один робочий протокол 3-го рівня — це ІР (4 та 6 версій) , все інше — це надбудови й приробки до нього (є ще всілякі стеки для мобільних мереж й різна пропієтарщина, але,на мою думку основний протокол 3 рівня сьогодні — це саме ІР) . З керуванням логіки маршрутизатора OF справляється на відмінно (навіть з додаванням логіки протоколів маршрутизації), а от логіка роботи фреймів на 2 рівні — це вже нова річ, до цього ще не підходили.

Кілька уточнень:
1. У статті в якості обладнання наводиться свіч. Це є більш маркетинговий термін, що включає в себе як L2, так і L3. Назви «комутатор» чи «маршрутизатор» навмисне не вживалися тому, що це обладнання може працювати як на L2, так і на L3, і в дата центрах вони можуть виконувати різні ролі залежно від їх місця розташування. Походження терміну більш детально описано в The «Switch Book: The Complete Guide to LAN Switching Technology».
2. Так, IP зараз є домінуючим, але не варто обмежуватися лише протоколами. Навіть на основі існуючих протоколів можна програмувати інші рішення щодо їх обробки, наприклад, нові методи класифікації, балансування навантаження тощо.
3. OF справляється зі стандартними рішеннями, що далеко не завжди задовільняє потреби, що і заставляє індустрію дивитися в інших напрямках. До того ж, якщо слідкувати за динамікою розвитку OF, можна помітити стагнацію протягом останніх кількох років, так як зацікавлення в ньому падає.

Багато писав , все перекреслив.
До побачення.

дают, только у Juniper например, нормальная поддержка Openflow только для МХ серии, а это уже совсем не свичи и ценник там не тот который ожидаешь от устройств уровня доступа.

MX — это умные маршрутизаторы , насколько я понимаю, в статье речь о коммутаторах.

я понял по другому то что нипасано по ссылке:
появился новый тип комутирующих чипов, быстрый как асики, но более гибкий в возможностях.
и для того чтобы в полной мере реализовать эти возможности и появился язык Р4.
отсюда вопрос, обрудования на базе этих ипов уже свободно доступно на рынке? его может купить любой желающий?

Пока что все в проектах, НЯП, хотя я совсем недавно начал это смотреть . Вообще тема интересная.

Ідея P4 полягає в забезпеченні гнучкості в програмуванні мережі. Це не обов’язково включає повний контроль над мережевим стеком. Всі вендори зараз дивляться в сторону так званого «гібридного режиму», який дозволяє використовувати весь стандартний стек, наприклад TCP/IP/Ethernet, з можливістю внесення часткових змін задля забезпечення специфічних потреб тих чи інших сегментів дата центрів.

Можливість опису програмованих частин мережевого чіпа разом з фіксованими описані в стандарті мови P4 16. Це дозволяє не винаходити велосипед заново, бо ніхто зараз не відмовиться від всіх напрацювань IEEE, але з можливістю кастомізації під свої внутрішні потреби.

Ух ти ! Спасибі велике за статтю ! Впроваждення підтримки Р4 — це справді спроба створення повністю керованого мережевого середовища на 2 рівні моделі OSI . Дуже цікава річ — де-факто це розширення Net DevOps принципів аж до прописування правил обробки фреймів. Річ нова і дуууже перспективна, як на мене.

Підписатись на коментарі