Pull to refresh

Инкапсулятор Etherblade.net и импортозамещение сетевых компонентов (часть вторая)

Reading time 5 min
Views 5.1K
image

В первой статье я хотел показать, что FPGA девелопмент — интереснейшее занятие, а реализация потокового инкапсулятора является достаточно несложным проектом, который вполне мог бы выступить в качестве академического проекта для студентов старших курсов или аспирантуры.

Даже несмотря на то что хардварный дизайн стоит того что бы заниматься им исключительно для удовольствия, в данной статье мне хочется уделить внимание практической ценности данного занятия. В частности, наш разговор пойдет от том как создать сетевую инфраструктуру для операторов связи с использованием инкапсулятора Etherblade.net, реализованного на FPGA.

Данный текст является некоторым экскурсом в сетевые технологии и для того чтобы уместить такую обширную тему в рамках одной статьи, я решил написать ее в контексте некоторого плана действий или, если желаете, ответа на следующий вопрос – «Как используя FPGA и опенсорс максимально эффективно заместить оборудование от Cisco и Juniper».
Итак, начнем.

Концепция SDN (software defined networking) против больших вендоров


Традиционно на протяжении десятилетий сетевое оборудование выпускалось такими гигантами как Cisco и Juniper. Сегодня, крупные сетевые операторы, разрабатывающие собственное сетевое оборудование, становятся новой нормой. Цель, которую они хотят достичь — независимость от поставщиков компонентов и лучший контроль над инфраструктурой.

В России, в силу политических причин, данный подход, связанный с заменой сторонних продуктов системами с бОльшим процентным содержанием локально разработанных интеллектуальных компонентов (intellectual property blocks или IP-cores) принято называть импортозамещением.

Следует понимать, что большие корпорации располагают огромным количеством инженерных ресурсов и опираются на вертикально интегрированную модель разработки. А что делать относительно небольшим производителям?

Дефицит ресурсов может быть компенсирован опенсорсом. А отсутствие вертикальной интеграции правильным распределением под-задач среди менее крупных игроков.

Архитектура сетевых устройств, традиционно производимых большими вендорами достаточно легко сегментируется. Что бы распараллелить процесс и выделить отдельные под-задачи, концепция SDN (software defined networking) предлагает сегментировать архитектуру сетевых устройств на уровни, в частности отделить уровень управления сетью (control plane) от уровня устройств передачи данных (data plane).

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

Итак SDN предлагает модель архитектуры сетевого маршрутизатора в десегрегированном виде. Наша задача — идентифицировать интересующий нас компонент в данной модели и приступить к его разработке.

«Начинаем с малого» — инкапсуляция на маршрутизаторах и SDN-оверлей


Естественно решить все потребности мира за один раз сложно. Таким образом при построении больших систем имеет смысл начинать с малого и делать систему расширяемой, что бы дополнительный функционал мог быть внесен за счет интеграции дополнительных блоков или модификации существующих. Под словами «начинать с малого» я имею в виду выделение некоторой законченной сетевой функции, достаточной для построения функционирующей системы.

В проекте Etherblade.net в качестве такой функций было решено реализовать механизм инкапсуляции сетевого трафика.

Инкапсуляция в сетях — обыденная вещь. Давайте «десегрегируем» маршрутизатор и рассмотрим как его компоненты соответствуют компонентам модели SDN и определим какое место инкапсуляция занимает в обеих моделях.

Для примера возьмем один из маршрутизаторов, показанных на рисунке в самом начале статьи и изобразим его на рисунке ниже – но уже в «препарированном» виде.
На том же рисунке противопоставим маршрутизатору альтернативную «overlay SDN модель», предоставляющую схожий функционал.

image

Верхний (зеленый) уровень — SDN control/orchestration plane. Это мозг системы, по сути микропроцессор на котором исполняется управляющий сетевой софт. В традиционных маршрутизаторах этот компонент встроенный. В SDN данный функционал принято выносить во внешний “orchestration-контроллер” – компьютер, обслуживающий множество сетевых устройств.

Средний (голубой) уровень — forwarding path. Основная роль данного уровня — предоставление сетевого транспорта (коммутация/маршрутизация трафика). В традиционных маршрутизаторах – данный функционал реализован в виде внутреннего коммутирующего блока. В нашей “SDN-overlay" модели, роль данного «коммутирующего» компонента может быть полностью редуцирована за счет прямого подключения edge-устройств (whitebox) к транспортной сети.

Нижний (оранжевый) — edge/access уровень. На данных компонентах как раз и происходят все манипуляции с сетевым трафиком такие как инкапсуляция и другие преобразования протоколов. Для данного уровня характерна высокая скорость обработки и детерминированный функционал – отличное место для ASIC/FPGA. В традиционных рутерах данный функционал реализован на линейных модулях (line-cards), в SDN это так называемые “whitebox-устройства”.

Таким образом, резюмируя вышесказанное, можно сказать что Etherblade.net – по сути проект по разработке “whitebox” устройств под “SDN-overlay”.

«Вперед в датацентры!!!» — инкапсулятор как функция NFV (network function virtualisation)


Разобравшись с тем как структурно выглядит разрабатываемая нами система, имеет смысл поговорить о вариантах ее физического воплощения.

image

Слева изображен Etherblade-инкапсулятор как отдельное CPE-устройство (кампусный вариант). Справа Etherblade-инкапсулятор реализованный внутри сервера (вариант для датацентров).

Интересно то, что реализовав инкапсулятор на плате с PCIe интерфейсом и “спрятав” данную плату внутри сервера мы фактически можем создать иллюзию виртуализации данной сетевой функции. Данный подход называется NFV – network function virtualization.

Концепция NFV предполагает избавление от внешних сетевых устройств, таких как файрволы, load-balancers и тд за счет виртуализации их функций внутри серверов. Реализация инкапсулятора в качестве NFV-функции дает нам возможность избавиться от физических “edge”-маршрутизаторов.

Итак, NFV это модно и удобно. Сложность в том что с точки зрения хардварного дизайна «обуздать» PCIe не так просто как ethernet. Если ethernet представляет собой серийный последовательный протокол, то PCIe — комплексный транзакционный протокол с множеством конечных состояний (по сути сетевой стек, реализованный в железе). Не стоит забывать что операционной системе для работы с устройством PCIe так же необходимы соответствующие драйвера.

Одним из наиболее элегантных решений проблемы представляется использование FPGA плат, подобных той, что изображена в самом начале статьи. Следующий рисунок демонстрирует архитектуру платы и оба варианта реализации инкапсулятора на ней.

image

Как видим, данная FPGA плата имеет на борту “внешние” сетевые адаптеры, которые по своей сути являются конверторами между ethernet и PCIe. Таким образом, реализация инкапсулятора на подобного рода устройствах дает возможность получить NFV “прямо из коробки” — без лишних заморочек с PCIe и написанием драйверов.

От «частного к общему» — создание открытого репозитория сетевых IP-cores


Нельзя не согласиться с тем, что сегодня имеется множество специализированных сетевых ASIC (например от Broadcom), которые могут перевести любой подобный проект в очередной рассказ из серии “Получаем удовольствие от работы с FPGA”. Скептицизм в данном случае уместен, тем не менее хочу напомнить, что проект Etherblade.net не ограничивается созданием отдельного сетевого устройства. Основная цель Etherblade.net – создание открытого репозитория параметризуемых и документированных IP-cores.

Данный репозиторий может стать эффективной базой для создания целого спектра сетевых устройств (включая самые экзотические), которые в свою очередь могут быть реализованны как на FPGA так и в виде ASIC.

На этом – заканчиваю. В следующей статье мы перейдем непосредственно к хардварному дизайну, а пока приглашаю познакомиться с проектом поближе на etherblade.net.
Tags:
Hubs:
+15
Comments 14
Comments Comments 14

Articles