SONiC: незавершённое отделение ПО коммутаторов от оборудования

Краткое резюме

Microsoft разработала SONiC для Azure и выпустила его через Open Compute Project в 2016 году, создав общую архитектуру на базе Linux, контейнеров и баз данных для коммутаторов от нескольких поставщиков оборудования.
Switch Abstraction Interface даёт SONiC общий словарь для программирования различных ASIC, но возможности платформ, масштаб, поведение при ошибках и поддержка по-прежнему зависят от реализаций вендоров и проприетарных SDK.
Управление в Linux Foundation расширило участие, не устранив влияния Microsoft. Технический авторитет, финансирование проекта, развитие SAI и производственная поддержка остаются разделёнными между несколькими институтами и коммерческими участниками.
SONiC расширяется на модульные корпусные системы, корпоративные коммутаторы и ИИ-фабрики до того, как единообразное соответствие и собственность на безопасность полностью созрели. Его доверие зависит от измеримого поведения, а не от широты списков поддержки.

Маршрут доходит до кремния через цепочку передач

Маршрут BGP в SONiC не перемещается напрямую из процесса маршрутизации в таблицу коммутации. FRRouting получает обновление, применяет политику и выбирает маршрут. Zebra передаёт состояние пересылки через интерфейс Forwarding Plane Manager, fpmsyncd записывает намерение приложения в APPL_DB, а служба состояния коммутатора (Switch State Service) определяет требуемых соседей, следующие переходы и интерфейсы. Затем запрос сериализуется в ASIC_DB, обрабатывается syncd, транслируется реализацией Switch Abstraction Interface вендора и проприетарным комплектом разработки (SDK) и, наконец, программируется в ASIC.

Эта цепочка объясняет и важность SONiC, и его сложность. Каждая граница позволяет одной части системы развиваться без прямого знания обо всех остальных компонентах. ПО маршрутизации работает с общей моделью приложения, а производители оборудования транслируют стандартные объекты коммутатора в инструкции, необходимые их кремнию. Та же разделённость создаёт и больше мест, где желаемое состояние, сообщаемое состояние и фактическое поведение пересылки могут расходиться.

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

SONiC выбрал второй путь. Он использует Linux как основу, разделяет сетевые функции на программные службы, обменивается состоянием через базы данных на базе Redis и размещает аппаратную абстракцию под сетевыми приложениями. Проект не устраняет различия в оборудовании и не предоставляет единый глобальный контракт поддержки. Он создаёт общий программный слой, который может пережить смену поставщика коммутаторов, контрактного производителя (ODM) или семейства ASIC, при условии, что кто-то выполнит и будет поддерживать специфичную для платформы работу под ним.

Экономическая ценность — в дезагрегации. Оператор может выбирать отдельно оборудование, кремний, дистрибутив операционной системы, интеграцию и поддержку, а не покупать их как один продукт. Операционное следствие — разделённая ответственность. Функция может существовать в релизе сообщества, но оставаться недоступной или вести себя иначе на конкретной платформе, потому что решающее ограничение находится в прошивке, драйверах, коде SAI вендора, SDK или физическом конвейере.

Azure превратил проблему парка устройств в открытую платформу

Microsoft разработала SONiC для Azure до его публичной презентации. Его происхождение — производственная проблема, а не абстрактное предложение по открытым сетям. Гипермасштабируемые операторы должны автоматизировать большие парки коммутаторов, менять ПО быстрее, чем это могут позволить обычные продуктовые циклы, и закупать оборудование у нескольких поставщиков, не поддерживая полностью разную операционную модель для каждого.

Microsoft объявила о передаче SONiC в Open Compute Project 9 марта 2016 года. Название расшифровывается как Software for Open Networking in the Cloud. Microsoft охарактеризовала его как набор программно-сетевых компонентов для коммутаторов и дополнила его Switch Abstraction Interface, или SAI. Это сочетание было необходимым, поскольку переносимая верхняя часть стека имела бы ограниченную ценность, если бы каждому приложению маршрутизации, оркестрации и управления всё равно требовалось прямое знание интерфейсов каждого производителя кремния.

SAI предоставил общий словарь программирования для объектов, включая порты, VLAN, маршруты, следующие переходы, соседей, записи контроля доступа, очереди, буферы, туннели и счётчики. Производитель ASIC или платформы мог реализовать эти объекты поверх своего SDK и конвейера пересылки. Приложения SONiC могли запрашивать стандартный объект, не встраивая проприетарные аппаратные вызовы в общий код.

Участие в Open Compute Project связало ПО с операторами дата-центров, контрактными производителями, вендорами коммутаторов и кремниевыми компаниями, уже работавшими над открытым оборудованием и совместным проектированием аппаратного и программного обеспечения. Microsoft принесла реальную рабочую среду, а более широкая группа — разнообразие оборудования, необходимое для проверки обещаний проекта. Ни один из этих факторов не сделал переносимость полной. Каждая платформа по-прежнему требовала интеграции загрузки, драйверов, управления температурой, работы с оптикой, реализации SAI, поддержки SDK и постоянного тестирования.

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

Эта история облегчает понимание нынешней роли Microsoft. Компания создала SONiC и накопила годы эксплуатационных знаний до установления нейтрального управления. Передача проекта не стёрла это преимущество. Она создала рамки, в которых другие компании могли инвестировать, управлять и вносить вклад, не притворяясь, что производственный опыт создателя стал взаимозаменяемым в одночасье.

Linux и Redis сделали коммутатор модульным — и сохраняющим состояние

SONiC обычно описывают как сетевую операционную систему на базе Linux, но один лишь Linux не объясняет его архитектуру. Хостовая система предоставляет ядро, доступ к устройствам и базовые службы. Основные сетевые функции работают в отдельных контейнерах, а базы данных на базе Redis обеспечивают общее состояние и интерфейсы обмена сообщениями, через которые службы координируют работу. Switch State Service преобразует намерение приложения в операции SAI, а процесс, обращённый к оборудованию, связывает эти операции с реализацией вендора.

Контейнерная структура исторически разделяет функции, включая маршрутизацию, Link Layer Discovery Protocol, Simple Network Management Protocol, агрегацию каналов, мониторинг платформы, базы данных, SWSS и синхронизацию ASIC. Разделение улучшает упаковку и организационную принадлежность, но в каждом случае его не следует путать с сильной границей безопасности. Сетевые службы могут разделять ресурсы хоста и требовать повышенных привилегий для взаимодействия с ядром и оборудованием. Их ценность в основном в том, что компоненты можно разрабатывать, перезапускать и обновлять, не компилируя весь коммутатор в один непрозрачный процесс.

Redis задаёт общий язык. CONFIG_DB содержит предполагаемую конфигурацию. APPL_DB передаёт намерение прикладного уровня по пересылке и обслуживанию к уровню оркестрации. ASIC_DB представляет сериализованные объекты SAI для процесса, обращённого к оборудованию, а STATE_DB фиксирует состояние готовности и зависимости во время работы. COUNTERS_DB хранит статистику интерфейсов и оборудования, используемую эксплуатационными инструментами и телеметрией.

Конфигурация может поступать через файлы, инструменты командной строки, gNMI, REST или другое управляющее ПО. Процессы-менеджеры преобразуют эти входные данные в операции приложения, а SWSS потребляет результирующее состояние. orchagent разрешает зависимости и создаёт запросы SAI, sairedis сериализует их в ASIC_DB, а syncd вызывает библиотеку SAI и SDK вендора. Компоненты, написанные на разных языках и поддерживаемые разными командами, могут координироваться через определённое состояние, а не через плотную сеть частных вызовов.

Результат — распределённый конечный автомат. Ключ базы данных может устареть, один писатель может обогнать другой, а приложение может принять желаемое состояние до того, как оборудование его отклонит. Счётчики могут нагружать путь к базе данных, а перезапуски требуют, чтобы несколько контейнеров восстановили согласованное представление о том, что должен делать коммутатор. Redis — не пассивная деталь реализации. Его схемы, сохраняемость и поведение при сбоях влияют на надёжность всей системы.

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

SAI сдвинул проприетарную границу, не устранив её

SAI — главная причина, по которой SONiC может поддерживать широко общую верхнюю архитектуру на нескольких семействах ASIC. orchagent может запросить маршрут, порт, следующий переход, запись контроля доступа, очередь, туннель или счётчик, не содержа вызовов SDK конкретного вендора. Это снижает связанность и даёт сетевым приложениям стабильную объектную модель, даже когда нижележащий поставщик коммутатора меняется.

Интерфейс не может сделать физически разные ASIC эквивалентными. Кремний различается по ёмкости таблиц, конструкции конвейера, архитектуре буферов, поддерживаемым комбинациям объектов, семантике счётчиков, функциям телеметрии, атомарности обновлений, обработке туннелей и поведению при перезапуске. Вендор должен отобразить объекты SAI на эти ресурсы, часто через проприетарный код и SDK, которые мейнтейнеры сообщества не могут проверять.

Две платформы могут поэтому рекламировать одну и ту же версию SAI, предлагая при этом существенно разное поведение. Одна может поддерживать таблицу EVPN большего размера, более сложную политику контроля доступа или более тёплый перезапуск, чем другая. Функция может требовать возможность кремния или расширение SAI, отсутствующие в более раннем чипе. Общий интерфейс сокращает объём изменений верхнего ПО, но не сертифицирует масштаб или результаты.

Граница управления усиливает техническую. SONiC перешёл в Linux Foundation в апреле 2022 года, тогда как SAI остался под Open Compute Project. Сообщества координируются, но их структуры принятия решений не идентичны. Новое требование в телеметрии, ИИ-сетях или scale-up Ethernet может потребовать одновременных изменений в приложениях SONiC, определениях SAI, реализациях вендоров, SDK и кремнии.

Поиск неисправностей идёт по той же цепочке. Действительный запрос может не сработать в общем коде оркестрации, адаптере вендора, SDK или самом оборудовании. Мейнтейнеры сообщества могут видеть ошибку SAI без доступа к проприетарному слою, который её породил, а производитель оборудования может поддерживать только конкретную комбинацию образа и SDK. Коммерческий дистрибутив может взять на себя большую часть этой интеграционной нагрузки, но SONiC сообщества не создаёт единый универсальный путь эскалации.

SONiC таким образом перенёс зависимость от вендора к более узкой и явной границе, обращённой к оборудованию. Это существенное архитектурное изменение. Оно не устранило зависимость, и при сложных отказах окончательный ответ всё равно может прийти от компании, контролирующей проприетарную реализацию ближе всего к ASIC.

Сверка состояния — цена модульности

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

Некоторые исторические проекты SONiC рассматривали сбои создания или установки SAI как фатальные. Остановка процесса может быть безопаснее, чем продолжение с неизвестным состоянием оборудования, но она может оставить коммутатор в состоянии, которое сложно восстановить. Более поздняя работа над обработкой ошибок ввела конструкции, включая ERROR_DB и обратную связь с приложением для выбранных объектов, таких как маршруты и соседи. Цель — дать асинхронному запросу устойчивый результат, который исходное приложение и управляющий клиент могут интерпретировать.

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

Тёплый перезапуск переносит ту же проблему в обновления и восстановление процессов. Цель — перезапустить ПО, не отбрасывая состояние пересылки и не прерывая весь трафик. Новый процесс должен согласовать то, что задумал предшественник, что содержит Redis и что продолжает делать ASIC. Изменения схем, устаревшие ключи или частично восстановленные зависимости могут превратить сохранение состояния в ещё один источник неопределённости.

Операторам поэтому нужно больше, чем успешный ответ на команду. CONFIG_DB может подтвердить, что запрос принят, APPL_DB — что он транслирован, а ASIC_DB — что объект SAI запрошен. Ничто из этого не доказывает, что пакеты идут по заданному пути. Аппаратные счётчики, внешние тесты трафика и сверка состояния остаются частью обычного процесса подтверждения.

Архитектура обнажает факт, который интегрированные системы часто скрывают: сетевая конфигурация — не одна атомарная запись. Это последовательность переходов состояния между компонентами с разным временем и поведением при сбоях. Надёжность SONiC зависит от того, насколько хорошо эти компоненты восстанавливаются после задержек, отказов, перезапусков и частичного завершения.

Корпусные системы умножают и масштаб, и отказы

Ранний публичный образ SONiC был тесно связан с коммутаторами фиксированной формы для дата-центров с одним основным ASIC пересылки. С тех пор проект расширился на коммутаторы высокой плотности, модульные корпусные системы и распределённые системы с виртуальными выходными очередями (VOQ) с несколькими ASIC пересылки, устройствами фабрики, линейными картами и компонентами управления.

Многочиповая (multi-ASIC) система может запускать отдельные экземпляры Redis, SWSS, syncd, маршрутизации, обнаружения каналов и агрегации каналов для каждого устройства пересылки. Каждый ASIC может иметь собственный экземпляр SAI и SDK. ПО должно определять, какие интерфейсы, соседи и маршруты принадлежат каждому пространству имён, как представлены внутренние каналы и как состояние перемещается между устройствами.

Более крупная система меняет область отказа. Маршрут может входить в один ASIC и выходить через другой, а канал на передней панели зависит от внутреннего пути фабрики. Счётчики, собираемые в отдельных пространствах имён, должны представляться как часть одного логического коммутатора. Одна линейная карта может перезапуститься, пока другие карты и плоскость управления продолжают работу, что заставляет ПО координировать версии, владение объектами и доступность фабрики между независимо сохраняющими состояние компонентами.

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

Релиз SONiC 202605 включал ограниченный тёплый перезапуск multi-ASIC как альфа-функцию для ограниченной топологии. Эта пометка так же важна, как и наличие функции. Она подтверждает активную работу по реализации, но ясно даёт понять, что устойчивый перезапуск в сложных multi-ASIC системах ещё не является повсеместно квалифицированной возможностью.

Поддержка корпусных систем расширяет актуальность SONiC для телекоммуникационных сетей, облаков высокой плотности и ИИ-инфраструктуры. Она также приводит проект в системы, где интегрированные вендоры накопили годы специфичной для платформ логики восстановления. Открытая архитектура может конкурировать, но покрытие тестами, последовательность обновлений и обязательства по поддержке растут быстрее, чем количество ASIC.

Управление определяет, можно ли эксплуатировать открытость

Общая операционная система для коммутаторов полезна, только когда операторы могут настраивать, наблюдать и обновлять её в масштабе парка. SONiC поддерживает инструменты командной строки, статическую конфигурацию, SNMP и работы с gNMI, YANG, REST, OpenAPI, Translib и механизмами валидации. Доступные функции всё равно зависят от релиза, модели данных, дистрибутива и платформы.

Управление, управляемое моделями, призвано транслировать внешний запрос в систему конфигурации на базе Redis. Модели YANG определяют допустимые структуры, а CVL и связанные компоненты могут отклонять некорректный ввод. Translib и сервисные компоненты отображают операции API в таблицы SONiC, позволяя контроллерам работать через поддерживаемый интерфейс, а не манипулировать внутренними базами данных напрямую.

Валидация схемы не может доказать, что запрошенная служба авторизована, совместима с другим изменением или поддерживается оставшимися ресурсами ASIC. В документированном проекте также описывались операции compare-and-swap без общего блокирования или отката. Разработчики приложений должны поэтому определять владение, параллелизм и компенсацию, а не предполагать, что уровень управления предоставляет универсальную транзакцию.

OpenConfig и gNMI показывают разницу между включением компонента и завершённой операционной функцией. SONiC 202605 включил sonic-gnmi 0.1, тогда как исходящая телеметрия OpenConfig YANG осталась альфа-функцией. Полезное заявление о поддержке должно указывать модель, путь, операцию чтения или записи, режим телеметрии, релиз и вендорский дистрибутив. Широкое утверждение, что коммутатор поддерживает OpenConfig, говорит слишком мало.

Легаси-интерфейсы остаются необходимыми. SNMP связывает коммутаторы с существующими системами мониторинга, LLDP предоставляет информацию о соседях, а сервисы платформы раскрывают вентиляторы, температуру, питание и оптику. Работы с BMC и Redfish касаются функций жизненного цикла out-of-band, но несколько связанных процессов в релизе 202605 также сохранили альфа-статус.

Корпоративные коммутаторы создают ещё один набор ожиданий к управлению. SONiC проектировался для гипермасштабируемых сред, операторы которых могут собирать образы, запускать квалификационные лаборатории и поддерживать прямые отношения с производителями оборудования. Кампусные сети и сети доступа требуют таких функций, как Power over Ethernet, spanning tree, управление доступом 802.1X и предсказуемое управление конечными точками, часто для команд без инженерных мощностей масштаба облака.

Рабочая группа PENS, охватывающая PoE и услуги корпоративных сетей, — одна из попыток закрыть этот разрыв. Другие группы занимаются управлением, платформенными операционными системами, интеграцией BMC, виртуальными плоскостями данных и документацией. Их существование показывает активную работу, а не единообразную зрелость. Корпоративное внедрение будет зависеть от перевода функций из проектирования и реализации через включение в релиз, квалификацию оборудования и поддерживаемую коммерческую поставку.

Коммерческие дистрибутивы становятся особенно важны на этой границе. Они могут предоставить протестированную поверхность управления, политику обновлений, матрицу оборудования и процесс поддержки вокруг компонентов апстрима. SONiC сообщества — это общая база; оператору всё равно нужна сторона, которая владеет жизненным циклом образа, фактически работающего на коммутаторе.

Название Foundation охватывает проект и целевой фонд

Название «SONiC Foundation» может предполагать отдельно зарегистрированную организацию с собственным уставным советом, сотрудниками и счетами. Доступные записи об управлении поддерживают более многослойное описание. SONiC Foundation — это технический проект и сообщество, размещённое под эгидой Linux Foundation, тогда как отдельно зарегистрированной компании SONiC Foundation или независимого некоммерческого юридического лица в предоставленных доказательствах выявлено не было.

Связанная структура — SONiC Fund — является целевым фондом Linux Foundation (Directed Fund). Он привлекает и тратит средства в поддержку технического проекта. Его управляющий совет (Governing Board) контролирует членство, бюджеты, информационную работу, политики и возможные программы соответствия. Технический руководящий комитет (Technical Steering Committee) занимается техническим направлением, и хотя он представлен в более широкой структуре, техническая и финансовая власть остаются раздельными.

Это разделение не позволяет членству стать заменой развёртывания или технического контроля. Компания может вступить в целевой фонд, не эксплуатируя SONiC в производстве. Место в управляющем совете не решает каждую проектную дискуссию, а участник может влиять на ПО, не покупая Premier-членство. Linux Foundation администрирует средства и товарные знаки проекта, тогда как права на код регулируются соответствующими лицензиями и авторскими правами участников.

SAI добавляет ещё одну институциональную границу, поскольку остаётся инициативой Open Compute Project. Проект SONiC разрабатывает общее операционное ПО, целевой фонд финансирует и продвигает эту работу, OCP размещает SAI и связанную аппаратную деятельность, а вендоры или операторы интегрируют полученные компоненты с коммутаторами и коммерческой поддержкой. Dell Enterprise SONiC и другие дистрибутивы находятся ниже по течению от проекта сообщества, а не превращают Foundation в обычного поставщика ПО.

Такая схема определяет, где находятся решения и ответственность. Рабочая группа и TSC могут формировать функцию, устав целевого фонда регулирует членские взносы, а участники OCP разрабатывают объект или версию SAI. Производственный сбой может по-прежнему требовать команды проприетарного SDK или поставщика, квалифицировавшего финальный образ. Рассматривать каждый слой как единый Foundation значило бы скрывать границы, которыми операторы должны управлять.

Нейтральное управление не стёрло влияние Microsoft

Linux Foundation объявила о переходе SONiC 14 апреля 2022 года. К тому времени проект перерос образ внутреннего стека одной облачной компании. Нейтральная рамка предложила совместное членство, финансирование, выборы, брендинг и техническое участие компаниям, которые иначе могли бы колебаться полагаться на управление под руководством Microsoft.

В объявлении говорилось, что SONiC уже работает на миллионах портов и более чем на 100 моделях коммутаторов, при более чем 50 партнёрах. Это были заявления проекта и создателя, а не независимая перепись. Тем не менее они показывают, что переход подавался как институционализация развёрнутой платформы, а не инкубация нового эксперимента.

Устав целевого фонда с поправками от 5 мая 2026 года позволяет Premier-членам назначать представителей в управляющий совет. Общие члены избирают представителей как класс в зависимости от численности членства, а ассоциированные члены мест в совете не получают. Совет обычно ограничен 19 голосующими представителями, если не увеличен, кворум составляет 50 процентов, а обычные решения принимаются простым большинством при наличии кворума, хотя консенсус предпочтителен.

Ежегодный взнос в целевой фонд для Premier-члена составляет 100 000 долларов США, отдельно от обязательного корпоративного членства в Linux Foundation. Взносы общих членов составляют от 1 000 долларов для организаций с числом сотрудников до 499 до 20 000 долларов для организаций с не менее 5 000 сотрудников. Одобренные ассоциированные члены участвуют без взноса в фонд. Linux Foundation взимает общие и административные расходы в размере 9 процентов с первых 1 млн долларов годовых валовых поступлений и 6 процентов сверх этой суммы.

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

Деньги — лишь одна часть модели вклада. Microsoft, облачные операторы, кремниевые компании, вендоры коммутаторов и интеграторы предоставляют инженерные ресурсы, порты платформ, реализации SAI, лаборатории, мощности непрерывной интеграции, документацию и работу над релизами. Ценность этих вкладов не публикуется единым финансовым итогом, и проект остаётся уязвимым, когда корпоративная команда меняет приоритеты.

Microsoft занимает наиболее заметный центр текущего руководства. На момент среза исследования Дэйв Мальц (Dave Maltz) возглавлял управляющий совет, Синь Лю (Xin Liu) — комитет по информационной работе, а Гохань Лу (Guohan Lu) — технический руководящий комитет. Microsoft также была создателем проекта, Premier-членом, активным участником и крупным производственным оператором.

Более широкое управление действительно мультикомпанийное. В управляющем совете были представлены Alibaba Cloud, Arista, Broadcom, Celestica, Cisco, Dell, Google, Marvell, Nokia, NVIDIA, PLVision, Upscale AI, Nexthop AI и другие. Выборы 2026 года в TSC дали одного председателя и восемь голосующих членов, связанных с Microsoft, Google, Broadcom, NVIDIA, Alibaba Cloud, Cisco, Dell, Marvell и одной независимой принадлежностью.

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

Преимущество Microsoft сочетает руководящие позиции с эксплуатационными данными Azure. Отказы, обновления и ограничения масштаба создают знания, которые публичные проектные документы редко фиксируют. Тест нейтрального управления поэтому состоит в том, могут ли другие организации владеть сложными подсистемами, оспаривать проектные решения и поддерживать релизы, если приоритеты Microsoft изменятся. Разнообразие совета даёт рамку; концентрация вклада и владение мейнтейнерами дали бы более сильное доказательство.

Релизы задают базовую линию, а не сертифицированный продукт

SONiC 202605 показывает, сколько ПО интегрирует современная сетевая операционная система. Релиз использовал Debian 13 Trixie, ядро SONiC 6.12.41, SAI 1.18.1, FRR 10.5.4, Redis 8.0.2, Docker 28.2.1 и Python 3.13.5. Он также объединил обнаружение каналов, агрегацию, SNMP, DHCP, анонсы маршрутов, телеметрию и платформенные пакеты, чья безопасность и жизненный цикл не движутся по одному графику.

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

Поэтому маркировка качества необходима. Релиз 202605 классифицировал исходящую телеметрию OpenConfig YANG, ограниченный тёплый перезапуск multi-ASIC, процессы BMC Redfish, операции с паролями самошифрующихся дисков, привязку телеметрии к VRF и механизм событий или сигналов тревоги как альфа. Пользователи могут оценить эти реализации, но включение в релиз не является обещанием стабильного поведения на всех перечисленных платформах.

Тестирование должно охватывать комбинации ASIC, коммутатора, топологии, функции, ветки и пути обновления. Публичные условия sonic-mgmt включают специфичные для платформ пропуски и ожидаемые сбои. Пропуск может означать неподдерживаемую функцию, ограничение теста, известную проблему или неприменимый случай, поэтому его не следует автоматически трактовать как дефект продукта. Более широкая картина всё равно показывает, почему фраза «поддерживает SONiC» слишком широка для закупок.

Осмысленное заявление о платформе определяет оборудование, ASIC, поставщика образа, релиз SONiC, реализацию SAI, SDK, протестированные функции и владельца поддержки. Тёплый перезапуск на одном коммутаторе фиксированной формы мало что говорит о распределённом корпусе. Масштаб контроля доступа на одном ASIC нельзя перенести на другой, а путь gNMI в образе сообщества может отличаться от интерфейса, предлагаемого коммерческим дистрибутивом.

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

ИИ-фабрики — самый острый тест общего слоя

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

В статье SONiC Foundation от июля 2026 года, написанной Гоханем Лу из Microsoft и Мехак Махаджан из Broadcom, описывалась архитектура Microsoft Fairwater и четыре возможности, объявленные доступными к релизу 2025.11: более высокий масштаб BGP, распределение трафика по источнику на основе SRv6, обрезка пакетов и высокочастотная потоковая телеметрия. В той же статье описан многоплоскостный мультирельсовый дизайн, рассчитанный на поддержку до 512 000 GPU. Это были заявления проекта и практиков, а не независимо проверенные доказательства того, что полное число работало одновременно.

Работа с BGP описывалась как поддержка 512 сессий на коммутатор, около 1 000 маршрутов и 512 следующих переходов в соответствующем проекте. Сообщалось, что FRR 10 и примерно 20 точечных патчей обеспечивают сходимость плоскости данных ниже 100 миллисекунд. Статья не приводила полную топологию, распределение процентилей, аппаратную спецификацию или воспроизводимую методику, поэтому эта цифра относится к описанной архитектуре, а не к универсальной гарантии производительности SONiC.

SRv6 и uSID решают проблему ограниченной энтропии, создаваемой небольшим числом очень крупных потоков. Пути, выбираемые конечной точкой, могут распределять трафик более осознанно, чем обычное хеширование, но механизм требует совместимых конечных точек или NIC, подходящего разбора ASIC, ёмкости таблиц, поддержки маршрутизации и восстановления после сбоев. Функция операционной системы работает только как часть согласованного стека.

Обрезка пакетов сохраняет короткий заголовок отброшенного пакета и пересылает его, чтобы получатель мог быстрее обнаружить потерю. В статье Foundation описан аппаратно-специфичный случай, в котором обрезанные заголовки с до 18 входных портов могут выйти через один выходной порт на текущем оборудовании с 512 портами. Результат зависит от ASIC и структуры трафика и не показывает, что каждая платформа или конечная точка SONiC поддерживает механизм.

Высокочастотная телеметрия призвана фиксировать события, пропускаемые более медленным опросом. Описанный путь использует экспорт счётчиков ASIC IPFIX, Counter SyncD, COUNTERS_DB и либо анализ на самом коммутаторе, либо экспорт OpenTelemetry в такие системы, как Prometheus или InfluxDB. Такая конструкция помещает Redis и обработку телеметрии в контур обратной связи ИИ-фабрики, увеличивая и их операционную ценность, и их нагрузку на производительность.

Членство движется в том же направлении. Upscale AI стала Premier-членом в феврале 2026 года. Supranett присоединилась на уровне Premier 28 июля, а Exaware, TeraHop и Infrawaves стали общими членами. Nexthop AI и другие компании ИИ-сетей также занимают позиции в управлении или рабочих группах. Членство демонстрирует инвестиции и намерения, а не развёртывание, но оно определяет проблемы, которые компании ожидают решать с помощью общей платформы.

Scale-up Ethernet приближает SONiC к акселераторным системам, которые исторически использовали специализированные межсоединения. Рабочая группа Scale-Up Ethernet призвана переводить новые требования, включая работы, согласованные с OCP E-SUN, в реализации, охватывающие повторные попытки на уровне канала, управление потоком на основе кредитов, адаптивное хеширование потоков, заголовки пакетов scale-up и более крупные фабрики конечных точек.

Возможность значительна. Зрелая реализация могла бы позволить одной открытой среде сетевой операционной системы обслуживать крупные фабрики масштабирования наружу (scale-out) и части формирующегося рынка scale-up Ethernet. Операторы могли бы переиспользовать практики управления, телеметрии и платформ на большей части ИИ-сети.

На момент среза исследования работа не достигла завершённого универсального стандарта или широкого развёртывания. Требования всё ещё развивались, вендоры могли раскрывать важные функции через расширения, а изменения должны были пересекать SONiC, SAI, ПО конечных точек, NIC, прошивку и кремний. По мере приближения SONiC к специализированному поведению акселераторов точная семантика оборудования становится важнее. Общий слой может расширяться, в то время как проприетарная граница под ним становится всё более значимой.

Безопасность стала формальной после того, как платформа уже была в производстве

Образ SONiC сочетает Debian, ядро Linux, среду выполнения контейнеров, Redis, FRRouting, службы управления, LLDP, SNMP, компоненты DHCP, пакеты Python, драйверы платформ, библиотеки SAI вендора, проприетарные SDK, прошивку и инфраструктуру сборки. Уязвимость в любом из этих слоёв может затронуть коммутатор или его плоскость управления, тогда как ответственность за исправление может быть разделена между несколькими проектами и поставщиками.

Публичная рабочая группа по безопасности была одобрена в июне 2026 года. В её область вошли сведения о составе ПО (SBOM), информация VEX (Vulnerability Exploitability eXchange), гигиена зависимостей, статический и динамический анализ, фаззинг, тесты на проникновение, безопасность цепочки поставок, усиление защиты и безопасная или измеряемая загрузка. Председателем назначен Брэд Хаус из Nexthop AI, сопредседателем — Ци Ло из Microsoft.

Документ о создании признавал, что значительная работа по безопасности ранее не имела достаточно чёткого владельца. Безопасность не отсутствовала: уязвимости обрабатывали апстрим-проекты, мейнтейнеры и вендоры, существовал процесс сообщений об уязвимостях. Признание состояло в том, что ответственность в интегрированной системе не была организована в видимый публичный поток работ, соразмерный производственному использованию платформы.

Рабочая группа не завершает эту задачу. Зрелая программа нуждается в актуальных SBOM, записях о происхождении, триаже уязвимостей, подписанных или воспроизводимых сборках, политиках патчей, обработке частных раскрытий, бэкпортах и специфичных для платформ бюллетенях. Проприетарные библиотеки SAI, SDK и прошивка осложняют картину апстрима, поскольку сообщество не может ни проверять их исходный код, ни контролировать их графики выпуска.

Службы управления заслуживают особого внимания. gNMI, REST, SSH и SNMP открывают привилегированное управление или информацию, требуя управления сертификатами, проектирования ролей, аудита, обращения с секретами и сетевой изоляции. Контейнеры улучшают упаковку, но не создают автоматически сильных границ безопасности, когда разделяют ресурсы хоста и требуют повышенных возможностей. Компрометация пути оркестрации или базы данных может затронуть множество объектов пересылки.

Коммерческие вендоры выпускают собственные бюллетени, потому что их продукты содержат разные комбинации и политики поддержки. Уязвимость в Dell Enterprise SONiC не должна автоматически обобщаться на каждый образ сообщества, а оператор не может предполагать, что страница апстрим-проекта покрывает каждый проприетарный компонент его коммутатора.

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

Открытый исходный код переносит затраты на поддержку, а не устраняет их

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

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

Многие предприятия и сервис-провайдеры нуждаются в поставщике, который примет на себя большую часть интеграционного риска. Dell предлагает Enterprise SONiC с квалифицированным оборудованием и коммерческой поддержкой. Nokia предоставляет образы SONiC сообщества и поддержку на выбранных платформах, а другие вендоры коммутаторов, контрактные производители и интеграторы упаковывают собственные комбинации. Эти предложения могут создать более ясный путь эскалации, но они могут расходиться по патчам, функциям управления, покрытию оборудования и срокам релизов.

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

Участники сотрудничают вокруг общего слоя, конкурируя выше и ниже него. Arista, Cisco, Dell, Nokia и NVIDIA могут вносить вклад в один проект, продавая при этом разные продукты. Облачные операторы могут поддерживать общие интерфейсы, агрессивно ведя переговоры с производителями оборудования, а компании по производству ASIC выигрывают, когда SONiC упрощает интеграцию их кремния, сохраняя дифференциацию в функциях и производительности.

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

Членские взносы делают финансовое участие видимым, но инженерные ресурсы, вероятно, более крупная валюта. Взнос Premier в 100 000 долларов значителен для фонда и мал рядом со стоимостью содержания специализированной команды или аппаратной лаборатории. Организации, годами предоставляющие реализации и тестирование, могут влиять на результаты через операционную реальность, даже когда устав формально отделяет оплату от технического признания.

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

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

Дезагрегация создаёт выбор только тогда, когда эти границы остаются видимыми. Иначе оператор может заменить блокировку одного вендора зависимостью от кастомного образа, одного интегратора или сборки SDK, которую невозможно поддерживать в другом месте. Открытая архитектура делает альтернативы возможными; контракты на поддержку и внутренняя инженерия определяют, остаются ли они пригодными.

Развёртывание значительно, но сопоставимость остаётся слабой

В объявлении Linux Foundation о переходе в 2022 году говорилось, что SONiC работает на миллионах портов и более чем на 100 моделях коммутаторов. В апреле 2024 года SONiC Foundation сообщила о 4 250 участниках из более чем 520 организаций и годовом росте сообщества на 20 процентов. В биографии в рамках управления указывалось, что Alibaba эксплуатирует почти 100 000 коммутаторов, шлюзов и маршрутизаторов на основе SONiC.

Каждая цифра указывает на масштаб, но ни одна не является независимой проверенной переписью. Итоги участников могут включать исторических участников, а не активных мейнтейнеров; поддерживаемая модель может иметь малый производственный объём; а членство в Foundation не доказывает развёртывание. Публичные заявления описывают разные единицы и не могут быть сведены в единую надёжную долю рынка.

Названные примеры дают более прочные свидетельства использования. Microsoft разработала и эксплуатирует SONiC в Azure. Alibaba, eBay и EPFL поддержали переход к Linux Foundation и описали своё использование. Orange сообщила о первоначальном производственном развёртывании примерно 90 коммутаторов в 2024 году и намерении расширяться, тогда как материалы Foundation позже выделяли SAKURAONE, Tokyo-1, Rakuten и индийские платёжные развёртывания. Dell и Nokia предлагают поддерживаемые продукты, привязанные к выбранному оборудованию.

Доказательств более чем достаточно, чтобы отвергнуть описание SONiC как экспериментального лабораторного проекта. У него производственное происхождение, активные репозитории, несколько партнёров по кремнию и оборудованию, коммерческие дистрибутивы и названные операторские развёртывания. Чего по-прежнему нет — так это согласованной меры активных систем, поддерживаемых наборов функций и сопоставимого поведения между платформами.

Это ограничение становится важнее по мере расширения SONiC в корпоративные сети и ИИ-фабрики. Совокупные показатели портов дают уверенность в категории, тогда как свидетельства уровня платформы определяют, поддерживаемо ли конкретное развёртывание. Операторам нужны релиз, ASIC, образ, матрица функций, история обновлений, история инцидентов и подотчётный поставщик.

SONiC находится между кастомным гиперскейлерным ПО и вертикально интегрированными коммерческими сетевыми продуктами. Arista EOS, Cisco NX-OS, Junos и Nokia SR Linux предлагают зрелые системы с одним поддерживаемым продуктовым отношением. NVIDIA Cumulus Linux — ещё один коммерческий подход на базе Linux. Dell Enterprise SONiC и поддерживаемые предложения Nokia коммерциализируют базу SONiC, тогда как DENT, FBOSS, Open Network Linux, Stratum и switchdev Linux представляют смежные открытые или операторские архитектуры.

Преимущество SONiC — масштаб общей экосистемы вокруг одной модели Linux, контейнеров, Redis, SWSS и SAI. Операторы могут проверять и изменять общий код, выбирать из нескольких аппаратных путей и переиспользовать части автоматизации между поставщиками. Его недостаток — интеграционная матрица, создаваемая этой свободой. Производительность и поддержка зависят от того, насколько успешно слои были собраны заново.

ИИ-сети повышают ставки, потому что покупатели закупают большие объёмы коммутаторов, требуя при этом новых функций быстро. Общая операционная система может сократить дублирующую интеграцию между системными и кремниевыми вендорами. Та же срочность может поощрять расширения, которые решают одно развёртывание, ослабляя переносимость. Рыночная позиция SONiC будет зависеть от того, будут ли его интерфейсы поспевать, не превращаясь в номинальные абстракции над несовместимыми реализациями.

Граница видима; подотчётность ещё предстоит доказать

SONiC изменил сетевую коммутацию, превратив внутреннюю архитектуру облачного оператора в общую программную платформу. Linux, контейнеры и Redis создали общую операционную плоскость. SWSS отделил намерение приложения от аппаратных операций, а SAI дал нескольким семействам ASIC общую объектную модель. Управление Linux Foundation обеспечило более нейтральную структуру, в рамках которой конкурирующие компании могли финансировать и развивать ПО.

Проект не сделал коммутаторы взаимозаменяемыми. Он не сертифицирует каждую перечисленную платформу, не устраняет проприетарные SDK и не предоставляет единый опыт поддержки. Релиз сообщества может содержать альфа-функции, а общая версия SAI может скрывать разные ёмкости, поведение при ошибках и характеристики перезапуска. Координация безопасности не может контролировать компоненты, которыми апстрим-проект не владеет и не видит.

Эти ограничения раскрывают реальный вклад проекта. До дезагрегации граница между оборудованием и ПО находилась в основном внутри одного поставщика. SONiC сделал большую её часть явной и оспоримой, позволяя операторам определять, какие функции общие, какие остаются специфичными для платформы и какая сторона приняла ответственность за конечную систему.

Следующий этап проверит, сможет ли эта граница оставаться связной по мере расширения платформы. ИИ-фабрики масштабирования наружу требуют быстрой сходимости и высокочастотной телеметрии. Scale-up Ethernet приближается к акселераторным системам, multi-ASIC корпуса увеличивают сложность состояния, корпоративная работа расширяет базу пользователей, а управление безопасностью должно охватывать большую цепочку поставок со смешанными источниками.

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

Поэтому наблюдаемый тест — не то, сколько продуктов носят имя SONiC. Это то, могут ли разные платформы демонстрировать сопоставимое поведение, переживают ли собственность на безопасность и обслуживание корпоративные изменения и может ли оператор переходить между поддерживаемыми системами, не перестраивая операционную модель вокруг ещё одной недокументированной зависимости.