Hardware: ASIC, FPGA (ПЛИС), SoC

Fpga = плис = Программи́руемая логи́ческая интегра́льная схе́ма (на печатной плате)
Использование GPU для ускорения обработки сетевых пакетов в ядре Linux
Есть Китайские ПЛИС, есть даже Воронежские (для специальных задач)
”CPU и FPGA – микросхемы общего применения, туда спецзакладку для сети запихивать накладно, а вот в специализированный сетевой чип, который примерно весь Blackbox со своими закрытыми процами внутри – святое дело)” (c)
Язык Verilog/VHDL. Оба они являются HDL – hardware description language. Т.е. языки аппаратного программирования. В целом разработка на Verilog/VHDL считается значительно более долгой в сравнении с ПЯВУ. Разрабатывать FPGA с одной стороны легко т.к. всегда видишь что происходит (на слайде стриминг схема), с другой сложно т.к. сигналов много.

Плюсы FPGA: Параллельность, предсказуемость, свобода в архитектуре и периферии
Зачастую для FPGA есть эмуляторы платы FPGA, чтобы ты мог свой код протестировать через эмулятор, без девайса
Частота 500 МГЦ для FPGA это нормально и даже много. Нужно понимать, что это не процессор. Причем чем сложнее разработанная схема, тем сложнее поддерживать нужную частоту (если сложная логика между элементами например). Аналогично и в ASIC.
Большая часть FPGA разработки в России и мире это военка (даже язык VHDL был разработан для US DoD – см. Выше), космос, авто – там, где требуется обработка чего то (трафика, видео) с жестко предсказуемой производительностью/задержкой. FPGA позволяет делать без задержек приложения/устройства с гарантией скорости их работы, что важно, например, в автомобильном производстве (automotive). Военка отсюда же вытекает. Так же на марсоходах используется FPGA.
Производители Altera (Intel)/Xilinx (AMD) (основные).
Часть блоков кода в проектах зачастую повторяемые (можно скачать/найти/купить).
В Cisco 6880 есть и ASIC (на интерфейсах) и FPGA (коммутационные матрицы). Можно как баги править, так и функционал добавлять через прошивку FPGA. В целом это достаточно типовая архитектура на сегодня.
Неплохая статья о разработке FPGA в контекте где пригождается TCL, много особенностей разработки на FPGA не только в контексте TCL (процесс, глюки софта и проч)
(Linkmeup подкаст FPGA) Зачастую реализации на базе FPGA невозможно положить за счет объема трафика/(D)DoS, потому что они могут обработать line rate трафика без потерь с неизменной задержкой от объема. FPGA, ASIC зачастую круты тем, что решения на чипе делаются еще до того как пакет полностью принят и в момент приема остается это решение только применить. Кроме того буферы входящие/исходящие никак не зависят друг от друга.
Пример описания Беркута Метротек: FPGA HDL (заложенная ими логика в FPGA – MAC control, генератор, анализатор, передача и прием пакетов), Linux (там пишется аппа которая реализует RFC 2544/Y-1564, интерейсы просмотра и управления). Для Linux пишется прошивка, чтобы FPGA там выглядил как обычный NIC и можно было даже перехватывать с нее данные обычным wireshark/tcpdump.
Бинарник хранится в постоянной памяти как прошивка для FPGA, далее при загрузке девайса происходит установка значений для блоков в соответствии с прошивкой. Причем в реализации у метротека под каждый тест своя прошивка – отдельная для RFC 2544, отдельная для Y-1564. При смене прошивки девайс перезагружается за пару секунд и способен начинать новый тест. Может быть частичная реконфигурация, тем посложнее – указание конкретных ячеек для переконфигурации, а не всех.
Таблица с asic/fpga datacenter коммутаторов cisco/arista/juniper/huawei

Network switch comparison Table, including ASIC and packet buffer.

С точки зрения импортозамещения нет российских FPGA/ASIC. Не полностью доверенные схемы поэтому в любом случае. При этом FPGA со своей/известной логикой (вплоть до проверок ошибок CRC) лучше чем западный ASIC с неизвестной логикой.
Intel (Altera) Stratix V используют в Беркуте Метротека (тестер/анализатор)
Крутые FPGA 10/100G – Altera (куплен Intel). Продают dev-kit за 5к баксов для 10G (Arria) и 20к (Stratix).

FPGA Altera
The main product lines from Altera (now Intel) are the Stratix, Arria and Cyclone series FPGAs,[1] the MAX series CPLDs and non-volatile FPGAs,[1] Quartus design software,[6][7] and Enpirion PowerSoC DC-DC power solutions.

Stratix
https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/all-development-kits.html
https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/dev-kits/altera/kit-stratix-iv-gt-100g.html
$19,995
https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/dev-kits/altera/kit-stratix-v-gx-100g.html
$24,995

Arria
https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/dev-kits/altera/kit-a10-gx-fpga.html
$4,495

Intel Quartus Prime – Intel Quartus Prime содержит все что вам нужно для разработки дизайна систем на базе Intel FPGA, SoC и Complex Programmable Logic Device (CPLD), начиная с самых основ и включая далее отладку взаимодействия, оптимизацию, верификацию и моделирование.

Создание ASIC

Те, кто идет по пути создания ASIC, программируют на FPGA плате обычно и только потом в ASIC переливают проверенную реализацию. Но многие разработчики как нишевых (напр. метротек), так и массовых девайсов (включая коммутаторы) не делают ASIC вообще – слишком рискованно, большие инвестиции, трудозатраты и риски неисправляемых багов, отсутствие гибкости по развитию.
ASIC часто делается в 2-3 захода, не с первого.
Time-to-market высокий (до нескольких лет – сложность разработки, большие вложения). Но в результате продукт дешевый, по сравнению с FPGA. А FPGA ту же задачу можно решить за неделю-месяц, причем без больших капитальных вложений.
ASIC вызженно в камне. Цена ошибки огромна, в отличии от FPGA. Миллионы долларов в помойку. Есть миллион и тысяча примеров, когда выпускалась партия сетевушек реализованных на ASIC, где позже находилась мелкая, но очень неприятная бага которую невозможно поправить на уровне драйверов и производитель краснея выпускал новую ревизию устройств, неся серьёзные убытки. Целая индустрия на этом. ТЕСТИРОВАНИЕ мега важно. В случае с FPGA, среднестатистическое исправление ошибок занимает две недели. Или быстрее, если косяк вышел совсем уж неприятный.
Можно делать как в FPGA все что хочешь, но зависит от бабок (если у тебя такой большой заказ что фабрика чисто под тебя будет печатать)
Код пишется, потом преобразуется в фикс-конфигурацию из транзисторов, потом ты тестируешь реализацию. Альтернативный подход (бюджетнее) – конвертация фиксированной конфигурации FPGA в ASIC, но производительность может быть хуже.

(START Verilog/VHDL, ds proxima, CheckPoint)

Сергей Платко (цифровые решения) в linkmeup подкасте о L7 балансировке рассказал о

DS PROXIMA (архитектура, технологии, сценарии)
FPGA/ПЛИС (преимущества и недостатки)
CheckPoint Maestro (метод балансировки)
методах балансировки (в первую очередь на NGFW)

Интересное:

Про решения ПЛИС/FPGA/ASIC :
- Считает что VHDL/Verilog плохо сравнивать с классическими языками программирования, он называет их языками описания аппаратуры. Программистов, которые рассказывали ему на собеседованиях о программировании на verilog и при этом описывали паттерны программирования на C – он таких не брал т.к. они в последующем плохо пишут код для ПЛИС/FPGA (т.е. так как в С правильно тут лучше не делать).
- Asic в 5-10 раз более производителен в сравнении с FPGA/ПЛИС на этой же технологии за счет исключения программируемости. Хотя ранее на одном из других подкастов linkmeup кто-то утвержал что asic и fpga сопоставимы по производительности, а основной вопрос в стоимости (fpga дороже) / гибкости (fpga гибкий и перепрограммируемый), что собственно помню я и процитировал Марат из linkmeup.
- в целом решения на базе ПЛИС считает востребованы и будут востребованы несмотря на то что сложную логику (парсинг и балансировка на основе L7 payload) в них не заложить и обычно это не делается, ПЛИС решения имеют преимущества в сравнении с реализованными на базе процессоров общего назначения включая dpdk ((явно имеются и другие технологии kernel bypass)):
  - решения на базе ПЛИС производительнее –
    - частота ПЛИС ниже процессоров общего назначения CPU, но FPGA могут работать полностью параллельно (за счет параллельной работы транзисторов), не псевдо-параллельно (очень быстрые переключения CPU) более производительно и детерминированно. При этом нужно понимать, что FPGA не быстрее CPU “вообще”, но быстрее и предсказуемее в узком классе задач, где можно реализовать параллельную обработку без сложной логики. FPGA/ ПЛИС и GPU работают параллельно, в отличии от CPU, который работает последовательно, но параллельная работа выполняется быстрее только для задач которые подвержены методам параллельной обработки, в то время как для задач CPU такого требования нет и как итог он более универсален, хотя и в ряде сценариев более медленный. Именно параллизация дает возможность обрабатывать FPGA/ПЛИС трафик быстрее чем процессору общего назначения потому что каждый следующий пакет не ждет обработки предыдущего (даже если первый еще обрабатывается второй пакет может уже обработаться т.к. он обрабатывается независимо от первого).
    - Сравнивает свое решение с софтовыми балансировками, в том числе западными – по производительности лучше некоторых западных, которые реализуют баланстровку на софте вплоть до «нам нужен один unit чтобы заменить с десяток западных балансировщиков». В контексте сравнения стойки против одного сервера так же утверждает что сервер на базе FPGA/ПЛИС стоит сопоставимых средст в сравнении с высокопроизводительным сервером на базе CPU ((Сергей Платко ; FPGA/ПЛИС используют покупные, но микрокод в нем полностью свой)).
  - на ПЛИС меньше задержки, а если они есть, они более предсказуемые/детерминированные
  - часто решения на базе ПЛИС надежнее
- broadcom в одной из версий своего asic trident реализовали большую по количеству записей таблицу соединений (conntrack), что позволяет этот asic использовать в задачах балансировки.
- конкретно у них Цифровых решений (dsol) основная компетенция именно в ПЛИС – собрали много граблей по которым сделали выводы

L4 балансировщик ds proxima на базе ПЛИС:

Ключевые отличия балансировщика от брокера:
- Балансировщик более умное устройство – балансировщики должны поддерживать много сетевых протоколов типо arp, ospf, bgp, vrrp для гибкой и функциональной интеграции их в сеть
- Healthcheck / Keepalive / динамическая отказоустойчивость – проверка балансировщиком работоспособности подключенных нод и переключение с текущего active на standby ноду, по практике ds integrity в 20% случаях (текущие пилоты) нужен только этот функционал (переключения с основного, но упавшего сервера на резервный – почтовый, веб, waf, tls шлюзы, ngfw) реализующий внешнюю отказоустойчивость сервиса (причем как зависание сервиса, так и обрыв линков, зависание коммутаторов и проч), а функционал балансировщика впринципе не требуется, при этом рекомендуется ставить два балансировщика (резервирование), а не только организовывать отказоустойчивость сервиса забыв о отказоустойчивости балансировщика
- Virtual IP – балансировщик ds proxima может распределить трафик приходящий на виртуальный IP (т.е. клиенты обращаются на этот адрес), причем в зависимости от порта несмотря на один IP адрес он может балансировать на разные группы балансировки (80/443 на waf/nginx сервера, 25 на почтовые сервера, 53 на DNS сервера и проч).
- Группы балансировки – на разные группы балансировки разные настройки (это в другой реализации есть и в брокере)
  - по тому на кого балансировать трафик,
  - как балансировать трафик (не только по hash от l3-l4 идентификаторов, но и по сессиям и объект на который осуществляется балансировка не порт, а next hop),
  - что подменять в адресации IP и портов,
  - как проверять доступность сервиса (keepalive),
  - как реагировать на недоступность активной ноды.

С точки зрения реализации балансировщика на своем примере считают самым сложным реализацию производительного решения именно на dataplane, далее сложен роутерный функционал control plane (необходим для встраивания балансировщика в сеть), менее сложны healthcheck (их просто много/они разнообразны)
Dataplane
- По их практике l7 балансировщик (т.е. умеющий заглянуть в l7 payload и делающих решения на основе этого) на уровне dataplane (не control/mgmt plane, там он по сути обязателен) может быть нужен, но основная потребность в l4 балансировщике на dataplane – l7 имеет преимущество в большей глубине погружения, но имеет серьезные недостатки в скорости обработки и потенциальном изменении сигнатур матчинга трафика как критерия балансировки (транспортная адресация более надежна) – привел реальный пример из жизни коллеги который от своего enterprise обучался F5, на обучении ему рассказали о их оборудовании и функционале L7, а когда коллега вернулся к себе оказалось что используется только L4 для надежности/простоты
- С dataplane балансировщика могут предоставлять информацию по tcp флагам (syn, ack, fin, думаю и остальным), но кейсы пока не особо понимают (возможно – мониторинг dos)
- На балансировщике могут балансировать и по хешам и по сессиям (round robin по сессиям – каждая новая сессия на новый сервер, least session/connections, etc – аналогич настроек haproxy). Для балансировки по сессиям к FPGA подключены отдельные DDR планки (эту память не использует процессор общего назначения, у него свои RAM планки) в которых хранятся сессии/история того что происходило с сессией (аналог conntrack). Информация по IP адресам next hop на которые балансируется трафик (real IP в терминологии яндекс) хранится в разных местах в зависимости от метода балансировки –
  - в случае балансировки по сессиям (least sessions, session round robin, etc) хранится в дополнительной подключаемой к FPGA RAM в таблице сессий,
  - в случае если балансировка по hash (без участия информации о сессиях), информация хранится в регистрах самого FPGA (внутренней памяти FPGA – десятки/сотни мегабайт в современных FPGA, там так же хранятся маршруты на тысячи next hop и пакетный буфер т.е. часть памяти под таблицы, часть под пакеты); при этом FPGA не перепрограммируется в случае если Control plane обнаруживает отказ одного из балансируемых IP, он отсылает на Dataplane специальный служебный пакет, который приводит к удалению/переписыванию регистра (ячейки памяти) с балансируем IP из внутренней памяти SRAM FPGA
Control plane и Management plane
- Control plane/management plane использует процессоры общего назначения по причине того что разработка это функционала на FPGA не разумна/не целесообразна. Так же с процессора общего надначения отсылаются и healthcheck.
- Control plane анонсирует virtual IP балансировки во внешний мир
- У них есть L7 на уровне control/mgmt plane (эти plane реализованы на обычном CPU), а конкретно в функицонале healthcheck – в виде http, помимо более низкоровневых типо link status check, ping. В том числе хотят сделать сценарный подход/скриптовые healthcheck, когда своим скриптом можно описать что проверять, как это делать и как реагировать на результаты проверки. Healthcheck отправляются от ip балансировщика, поддерживаются до 32 нод в одной группе балансировки. В случае неуспешного ответа/ряда ответов из группы балансировки могут осуществляться те или иные действия:
  - удалятся определенные ноды (balancing)
  - нагрузка переключатся на пассивную ноду (failover)
Схемы балансировки на NGFW
- В текущей их реализации ds proxima для схемы балансировки на NGFW основная схема это балансировка на virtual IP, т.е. клиенты не терминируются по L2 на NGFW, а маршрутизируются балансировщиком в сторону NGFW
- При этом при использовании их брокера ds integrity клиенты по L2 терминируются на NGFW (vlan прокидываются до NGFW), брокер балансирует трафик на порты и использует (в случае с ds integrity точно) функцию mac rewrite (в сторону ngfw подменяется mac на тот, который использует ngfw за этим портом) и именно эта схема ближе к решению балансировки checkpoint maestro (т.е. по факту ds integrity ближе к checkpoint maestro в сравнении с ds proxima)
  - в checkpoint maestro балансировщиком является по сути брокер (dataplane работающий на низком уровне модели OSI) с дополнительными интеллектуальными фичами на уровне control plane, а не L4-L7 балансировщик, на брокере нет терминации L3 трафика (т.е. брокер балансирует на порты, а не на next hop); такая схема в целом лучше с точки зрения ИБ в сравнении с L3 (Сергей Платко)
  - при этом в случае необходимости отказоустойчивости каждого конкретного ngfw в такой схеме с ds integrity нужно дублировать каждую ноду ngfw в виде кластера active-standby, в итоге если в группе балансировки 10 firewall для отказоустойчивой схемы нужно 20 firewall! Есть еще альтернатива такой схемы в виде возможности дублирования (зеркалирования) трафика на стороне брокера (судя по всему две ноды как активные и не знают друг о друге) и дедупликации дублей после ngfw брокером, при этом в случае падения одной из нод схема не меняется никак, но такой схемой на практике заказчики не пользовались (“не нашлось желающих платить за такой функционал» Сергей Платко).
Кластеризации в текущей реализации балансировщика у них нет, предлагают кластеризовать балансировщик только внешними средствами (роутер перед балансировщиками отвечает за отказоустойчивость/переключение между активной и пассивной нодами), из возможных протоколов/технологий для этого говорят о bgp, bfd, lag, vrrp

(END Verilog/VHDL, ds proxima, CheckPoint)

SoC

Сейчас Метротековцы активно работают с относительно новой платформой — SoC (System on Chip). Смысл SoC — размещение функциональности полноценной системы в одном чипе. Например, можно объединить ARM, FPGA и кусочек памяти под одной крышей. Это даст огромную скорость внутренней коммуникации в рамках одного кристалла, освободив от узких мест в виде разнообразных шин передачи данных. Скорость зависит от кристалла, но обработка данных на скорости 560 Гбит/с совершенно реальные цифры.

FPGA + Python

статья на habr

Из песочницы
Технология FPGA (ПЛИС) в настоящее время обретает большую популярность. Растёт количество сфер применения: помимо обработки цифровых сигналов, FPGA используются для ускорения машинного обучения, в blockchain технологиях, обработке видео и в IoT. 

Данная технология имеет один существенный минус: для программирования используются довольно старые и специфичные языки описания цифровой аппаратуры Verilog и VHDL. Это осложняет вхождение новичка в FPGA и для работодателя найти специалиста с этими специфичными знаниями на рынке труда сложно. С другой стороны популярный высокоуровневый язык программирования Python с фреймворком MyHDL делают программирование FPGA простым и приятным. Тем более людей знающих Python на порядок больше специалистов владеющих Verilog/VHDL. Серией статей я хочу показать как легко и просто войти в область FPGA зная Python и начать делать настоящие сложные FPGA проекты на этом языке.

Создание ASIC

FPGA + Python

Leave a Reply Cancel reply