HighLoad++ 2017
Зал «Калининград», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3021.html
Одним из ключевых инновационных трендов в современных сетях является дезагрегация, при которой аппаратная платформа сетевого устройства отделяется от операционной системы и приложений, что позволяет использовать различные ОС на различных устройствах, а также запускать различные сетевые приложения на этих ОС.
Если в мире серверов дезагрегация и создание унифицированной открытой аппаратной платформы на базе архитектуры x86 и IBM PC, произошло десятки лет назад, то в мире сетей этот подход только начинает набирать обороты.
...
3. Дезагрегация в IT-инфраструктуре
Apps
OS
HW
Mainframes
HW
OS
Apps
X86 commodity servers
HW
OS
HW
OS
HW
OS
Microservices
Scale-out architectures
HW
Net Apps
NetOS
Whitebox switches +
Vendor NetOS
Vendor (blackbox)
switches
APP
OS
HW
HW
NetOS
HW
NetOS
HW
NetOS
Net Apps
Whitebox switches +
Open NetOS + Open Apps
1980+ 1990+ 2000+
2000+ 2010+ 2015+
4. Открытость в IT-инфраструктуре
Открытая
архитектура
Server HWCPU
Intel
AMD
ARM
HPE, Lenovo,
Cisco, Dell EMC
Supermicro
OS
Linux
Windows
*BSD Открытая
платформа
Cross-Platform Apps
Apache, Nginx,
PostreSQL, etc.
Открытая
архитектура
Whitebox
Switch HW
ASIC
Broadcom
Mellanox
Cavium
…
Edgecore,
Mellanox,
Quanta, etc.
OS
Cumulus, Pica8,
BigSwitch, Open
Linux, etc. Открытая
платформа
Open Apps &
Protocol Stack
Quagga, Bird,
Snaproute, SNMPd,
etc.
5. Почему это актуально?
• Экономический эффект
• Выбор SW отдельно от HW
• HW дешевле, SW дешевле или бесплатно
• Проще и гибче в эксплуатации
• Нет привязки к одному вендору во всем
• Можно самостоятельно расширять функционал
• Надежно и проверено
• Facebook, Google, MS и пр. Web2.0 уже используют
• Сформирована целая экосистема Open Networking
• Есть поддержка от HW- и SW-производителей
8. Коммутатор = сервер + ASIC? Или нет?
• Не совсем
• ASIC != CPU
• Нет стандартной архитектуры ASIC
• ASIC передает пакеты на скорости (data plane)
• CPU запускает ОС и приложения
• Приложения управляют ASIC через API (control plane)
• NetOS != Server OS
• Управляет периферией коммутатора
• Предоставляет доступ приложений к ASIC
• Пользовательские интерфейсы (CLI, Web, API)
• NetApps != Regular Apps
• Реализуют сетевой функционал
• Формируют forwarding-таблицы сетевых протоколов
• Программируют ASIC в соответствии с таблицами
CPU
NOS
Apps
9. • Традиционные NOS
• Cisco IOS, IOS-XE, IOS-XR, NX-OS
• Juniper JunOS
• Arista EOS
• Коммерческие NOS
• Cumulus Linux
• Pica8 PicOS
• Big Switch SwitchLight
• IPinFusion OcNOS
• Pluribus Netvisor OS
• Открытые NOS
• Open Network Linux (ONL)
• SONiC
• OpenSwitch
• Linux (Ubuntu, Debian, Fedora,
etc.)
Closed Hardware
Closed OS
Closed Apps
Open Hardware
Closed OS
Closed or Open Apps
Open Hardware
Open OS
Open Apps
Основные виды сетевых ОС для коммутатора
10. NetApps? Или чем и как программируется ASIC?
• Protocol Stack
• Функционал сетевых протоколов
• Bridge, STP, OSPF, BGP и т.п.
• Формирует forwarding-таблицы для
программирования ASIC
• Forwarding Agent
• Middleware между Protocol Stack и ASIC
• Программирует ASIC на основании
сформированных fwd-таблиц
• Использует специфичный API
• API
• Для каждого ASIC – свой (vendor SDK)
• Broadcom, Mellanox, Cavium, Marvell, etc.
• Открытые прослойки для абстракции
• SAI, OpenNSL, OF-DPA, etc.
ASIC
Vendor SDK
Abstraction API
Forwarding Agent
Linux OS
Linux kernel
Linux Native APIs
(Neltink)
Protocol Stack
Linux Network Stack
11. Архитектура сетевых ОС для коммутаторов
OS Kernel
Switch Hardware
CPU Platform HW ASIC
ASIC kernel
drivers
Forwarding
Agent
Proprietary
ASIC SDK
Protocol Stack
Традиционные NOS
Linux Kernel
Switch Hardware
CPU Platform HW ASIC
ASIC kernel
drivers
Forwarding
Agent
Proprietary
ASIC SDK
Protocol Stack
Коммерческие NOS
на базе Linux
Linux Kernel
Switch Hardware
CPU Platform HW ASIC
ASIC kernel drivers
Forwarding
Agent Proprietary
ASIC SDK
Protocol Stack
Abstraction APIs
Открытые NOS
на базе Linux
Binary blobProprietary SWOpen/Free SW
12. От открытых NOS к Linux-коммутатору
Linux Kernel
Switch Hardware
CPU Platform HW ASIC
ASIC kernel drivers
Forwarding
Agents Proprietary
ASIC SDK
Protocol Stack
Abstraction APIs
Открытые NOS на базе Linux
Linux Kernel
Switch Hardware
CPU Platform HW ASIC
Open
ASIC kernel driver
Protocol Stack
Linux Network Stack
Netlink
Открытый Linux в качестве NOS
Open source
Нет закрытых/проприетарных компонентов
Драйвер ASIC в upstream ядра Linux
13. Поддержка Switch ASIC в ядре Linux
• OpenWRT swconfig
• Чипы для домашних роутеров
(Atheros, Broadcom, Realtek)
• Нестандартный способ настройки
интерфейсов
• Нет интерфейсов в системе
• User-space-утилиты
• Не принят в upstream
• DSA
• Чипы для домашних роутеров
(Atheros, Broadcom, Realtek)
• Порты как net devices
• L2 функционал
• В upstream с 2.6
• Switchdev
• Абстрактная модель драйверов
Switch ASIC в ядре Linux
• DSA – один из драйверов switchdev
• Порты как net devices
• L2, L3, ACL, QoS, etc.
• Чипы high-end-коммутаторов
(Mellanox)
• В upstream с 4.4
Основной фокус разработки
14. Switchdev
• Модель драйверов Ethernet-коммутатора
• Инфраструктура для Data Plane offload
• Базовые примитивы и механизмы offload:
• Netdev-представление физических портов ASIC
• Port state management, Port topology
• L2 forwarding offload (FDB, MDB, STP)
• L3 routing offload (FIB, ARP, ND)
• TC offload
• Драйверы switchdev
• mlxsw – Mellanox Spectrum ASIC
• DSA – BRCM, Marvell, etc. low-end ASIC
• SR-IOV-драйвер
• Rocker – виртуальный драйвер
15. Архитектура Linux-коммутатора на Switchdev
NetOS
User Space
Hardware
Kernel
NetApps
Ядро Linux с драйвером Switchdev
Сетевой стэк Linux
16. mlxsw – Mellanox Spectrum ASIC driver
• Открытый драйвер Mellanox Spectrum
ASIC в ядре Linux
• Каждый порт – как отдельный NIC
• Операции с портами:
• Коммутировать (L2)
• Объединяться в Bond (LACP)
• Разделять на под-сети (VLANs)
• Маршрутизировать (L3 routing)
• Фильтровать (ACL)
• Приоритизировать (QoS)
• Запаковать трафик в туннель
• Выгрузка состояния сети Linux в ASIC
• Трафик идет через ASIC
mlxsw_pci
mlxsw_core
mlxsw_spectrum
Port netdev
sw1p1
Port netdev
sw1p2
Port netdev
sw1pN
Switchdev infrastructure
bridge
(L2)
tc
(Traffic
Control)
ip
(L3)
FDB APIs Flow APIs FIB APIs
Operations Notifications
User Space
Kernel
p1 p2 pN
17. Текущий функционал и поддержка
дистрибутивов
• Функционал в switchdev
• L2 switching
• Bridging, Bonding, VLANs, STP, LLDP, FDB
learning/aging, IGMP, SPAN
• L3 routing
• IPv4/IPv6, Mcast, ECMP, VRFs, GRE
• L3 stack – Quagga, Bird, FRR, GoBGP, etc.
• Policy switching
• ACLs (TC Flower), OpenFlow (OVS)
• Platform mgmt: LED, Fan, PS, Sensors
• Specials: Port splitter, QoS, DCB, Buffer
mgmt, Port/traffic mirror
• Дистрибутивы
• Любой с ядром 4.8+
• Ubuntu, Fedora, Debian, RHEL, ALT
• Protocol Stack
• Open-source-приложения
• L3: Quagga, Bird, FRR, XORP, GoBGP,
ExaBGP
• Другие: mstpd, lldpd, vvrpd, etc.
18. Кто и как этим пользуется?
• Тот, кто хочет сэкономить и не боится Linux+немного хакинга
• Или кому нужна своя NetOS с минимальными затратами
• Простые, доверенные среды с минимальным функционалом
• Важна прозрачность и открытый код
• Финансовые компании, гос. сектор, оборонка
• Инфраструктуры с Linux end-to-end
• Важно единство инфраструктуры
• L2-, L3-функционал, интеграция с DevOps
• Академии, университеты, экспериментаторы
• Исследования новых протоколов и топологий
• Segment Routing, Load Balancing, SDN, etc.
19. Linux != NetOS из коробки
• Нужно немного доработать напильником
• Выбор подходящего Protocol-стека
• Управление и хранение конфигурации
• Мониторинг
• ONIE-загрузчик
• Chassis management коммутатора
• Механизмы обновления
• Доп. фичи: CLI, API, MLAG, sFlow/Netflow
• Для 90% функционала уже есть open-source-реализация
• Остальные 10% – можно разработать самим
20. Итого
• Модель whitebox – ключ к дезагрегации и открытости в сетях
• Многомиллиардная экосистема HW, SW, Apps вокруг whitebox и
Open Networking
• Открытые решения набирают популярность в SW
• Модель open-source в сети продавливается крупнейшими Web 2.0-
игроками
• Linux – основа большинства открытых NOS для whitebox
• Но они не исключают закрытые компоненты – ASIC SDK
• Switchdev+Linux+Whitebox = open source Linux-коммутатор
• High-end-сеть с 100% open-source SW – это реально!
• Функционально и уже используется в production
23. Топология CDN
User1
Узел CDN
Сеть ISP пользователя
Транзитная
AS
Транзитная
AS
Транзитная
AS
Узел CDN
Инфраструктура + ISP
Заказчика
24. Сетевое оборудование типовых PoPs
• Задача: расширение точек присутствия
• Базовые требования:
• Десятки серверов (10-40G)
• До 10 внешних подключений (10-100G)
• Функционал «все в одном»:
• L3-коммутатор, ACLs
• BGP-маршрутизатор, TCAM на 100k+ маршрутов
• Работа в плюс
ISP1 ISP2 IX
BGP BGP BGP
NGENIX PoP
25. Почему whitebox?
• Почему бы и нет? Базовый функционал уже стабилен
• Широкий выбор сетевых ОС
• Cumulus Linux
• Любимый Linux (с использованием switchdev)
• ОС от производителей оборудования
• Возможность работы как с серверами
• Унификация с серверами
• Удобно для автоматизации и мониторинга
• Возможности доработки и интеграции
• Экономика: HW – дешевле, OS – бесплатно (почти)
26. Тест -> пилот -> production
• Пилот подтвердил готовность к production
• HW: Mellanox Spectrum SN2410 switch (48x25G + 8x100G)
• SW: Ubuntu Server 16.04, kernel 4.10, switchdev
• Внешние подключения: 80 Gbps
• Задействованный функционал:
• L2 – bridge, link aggregation, VLANs, Jumbo Frames
• L3 – VLAN interfaces
• Routing stack: Quagga
• 10 BGP-сессий
• 71k IPv4-префиксов
• Особенности эксплуатации
• Гибрид сервера и классического коммутатора
• Особенности Open-Source ОС на коммутаторе
27. Год жизни с “белым ящиком”
• Выводы по итогам:
• Решение стабильно рабочее
• Не без сюрпризов, но с ними можно жить
• Модель whitebox экономически эффективна
• Удобно в эксплуатации
• Есть возможности самостоятельного расширения функциональности
• Инженеру на заметку:
• Коммутатор – НЕ просто сервер с большим числом NIC, есть особенности.
• За Open-Source приходится платить некоторым отставанием SW от возможностей HW
• Планы по whitebox на ближайшее будущее:
• Активно переходим на whitebox на типовых PoPs
• + 700Gbps, десятки BGP-сессий, сотни операторов (с учётом IX’ов)
• Дополнительная функциональность
Кратко о специфике Ngenix (для раскрытия дальнейшего кейса с Whitebox):
что такое CDN и какие бывают объёмы трафика
почему нельзя весь трафик отдать из одного ЦОДа ( каналы операторов и стыки, надёжность)
Одна из важных особенностей сетевой компоненты CDN – это баланс между количеством узлов и связностью на узлах для обеспечения наиболее эффективной доставки контента.
Использование большого числа маленьких узлов неэффективно с точки зрения эффективности кеширования.
Единичные Mega PoPs – не обеспечивают достаточного качества связности и уровня отказоустойчивости.
Оптимальная схема – десятки узлов с подключениями к различным крупным операторам связи и IX’ам
Задача - расширение точек присутствия в CDN
Нужны разные подключения
Выбор оптимальных решений с точки зрения цены/эффективности
На серверах/кэшинг/мониторинг узлах уже давно используются стандартные серверы с Linux + свое ПО
Хотелось аналогичного подхода для сети, так как ранее использовались брендовое железо (Cisco/Arista/Jun/etc).
Решили посмотреть на Whitebox коммутаторы - новый, но уже устоявшийся подход в современных компаниях со своей экосистемой и устоявшимся рынком.
Отдельно выбирали HW и SW (сетевую ОС):
HW - надежность, производительность, наличие поддержки
SW - функционал, простота, унификация с существующими инструментами управления (скрипты, рецепты Chef)
Сначала связи в тест на 3 недели для обкатки и начального знакомства с решением.
Тестировали Cumulus Linux (коммерческая ОС для коммутаторов) и новый интересный open source проект - switchdev на базе стандартной Ubuntu.
Остановились на последнем:
бесплатно
та же ОС, что используется на серверах (те же кастомизации и скрипты, Chef рецепты для DevOps)
некоторые фичи реализованы удобнее (например, split портов)
После теста - пилот (next slide)
Результаты:
В продуктиве уже около года времени
Оборудование - коммутатор Mellanox
ОС - Ubuntu Server 16.04 с драйвером switchdev
Текущий уровень нагрузки (Avg/Peak)
Особенности эксплуатации whitebox и Linux с switchdev:
Это гибрид со своими особенностями: консольный доступ, особенности аппаратной реализации. Плюсы – удобство и унификация. Минусы - например, аппаратно связанные первые биты mac-адресов.
Open-Source: всегда в движении, но сыровато; например, счётчики по vlan-интерфейсам появились недавно, есть некоторые неочевидные ограничения на последовательность внесения изменений.
Но все эти особенности вылезают на этапе настройки или модификации, а к стабильности работы вопросов нет.
Планы на будущее
Расширение проекта и более широкое применение whitebox
Задействование новых возможностей, в т.ч. для дополнительного healthcheck’инга и балансировки нагрузки, ну и ACLs
Рост нагрузки и объемов