Модели и языки

Однако вернёмся к NETCONF: в чём его фундаментальная проблема? Да в том, что он вышел в мир один одинёшенек. Не было предложено никаких схем, языка, стандартов для семантики. И всё пошло вразнос.

Модели были нужны, но языка для их описания не было. До 2010 (на самом деле больше) каждый вендор писал их кто во что горазд.

YANG, который (по-)меняет мир

Очень странно это, конечно, вышло. Для SNMP IETF много думали, работали и выпустили сначала язык спецификации SMI, а потом даже замахнулись на SMIng - nextgen, так сказать.

То есть необходимость языка описания спецификации была очевидна уже тогда - в 90-е, однако к NETCONF язык не приложили почему-то.

Впрочем это всё-таки довольно быстро стало понятно - в 2008 из осколков рабочих групп по SNMP слепили рабочую группу IETF NETMOD, которая в срочном порядке занялась разработкой языка. Не мудрствуя лукаво, они взяли синтаксис SMIng и «адаптировали» его. Уже в 2010 они выпускают YANG 1.0, а в 2016 - 1.1.

YANG - Yet Another Next Generation - по сути - это язык описания моделей. То есть это не данные и даже не конкретные модели - только язык. Как русский - это не произведение и не слова.

А уже с помощью этого языка создаются непосредственно модели, которые обычно так и называют - YANG-модели.

Модели на языке YANG далее могут преобразовываться в XML/JSON-схемы или в gRPC Protobuf’ы или во что угодно другое, что станет спецификацией для протокола.

И уже на основе этой спецификации можно генерировать конфигурации или проверять их валидность.

Четырёх лет задержки оказалось достаточно, чтобы вендоры понаделали кучу своего, на что завязали инструменты и они сами, и их заказчики.

Четыре года задержки откинули внедрение Model-Driven подхода лет на десять. Только сегодня хоть что-то похожее на практическое применение начинает выходить за пределы гуглов и фейсбуков.

Кстати, будьте аккуратнее, когда ищете «yang models» в интернетах, серьёзно вам говорю.

Виды моделей

Вендоры очень быстро сориентировались в ситуации на самом деле - и довольно скоро насоздавали YANG-модели для своих устройств.

Проприетарные, они же Native

У каждого производителя набор моделей свой собственный, никоим образом несовместимый с любыми другими. А зачастую просто даже ничего похожего между ними нет.

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

Где их можно взять?

Говорят, что можно прям запросить с устройства YANG-модель через операцию <get-schema>, но не все вендоры это поддерживают.

Говорят, некоторые вендоры выкладывают модели в GitHub, но не все и не всё.

Говорят, что можно скачать модели с сайта производителя.

Пусть говорят: но универсального пути тут нет, увы.

Главное: с этим уже можно было жить.

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

При этом казалось бы - вся сеть - это конечный набор одинаковых сервисов, если выбросить всякие IGRP, HSRP, RRPP и прочие проприетарные выдумки. Ну, всем же нужен IP, OSPF, BGP? Всем нужна аутентификация на устройствах и SSH? Они не могут иметь очень уж принципиальные отличия, как минимум из-за необходимости поддерживать совместимость друг с другом и соответствовать RFC.

Так почему мы делаем это сотней разных способов?

Сделать по отдельности у каждого вендора Configuration State Management - одноразовая, решаемая (а много где и решённая) задача. А вот договориться между всеми производителями, как должна выглядеть универсальная модель - так же сложно, как и любая другая задача, где людям нужно договориться.

Но ни один из зарождавшихся и выживших стандартов или не ставил целью унификацию вообще, или пытался поднять этот вопрос, но был выброшен в окно штаб-квартиры вендора.

Хотя вру. IETF предприняли отчасти успешную попытку написать универсальную модель.

IETF-модели

Разработав язык YANG, инженеры IETF поняли, что напрашивается и мультивендорная модель.

Ещё в 2014-м году были сделаны первые коммиты с этой моделью в репозиторий YANG.

С тех пор много накоммичено, но мало фактически сделано. Общепризнанно, что IETF-модель очень медленно развивается, у неё низкое покрытие, а схема не выдерживает критики.

С IETF-модели рекомендуют начинать, потому что она якобы проще, а уже потом переходить на OpenConfig, но как по мне - это напрасная трата времени.

Будущее её туманно, если не сказать непроглядно. Однако вендоры её поддерживают. Ну, кстати, Openconfig-модель из IETF-модели тоже кое-что импортирует, например, частично описание интерфейсов.

Заказчиков и пользователей беспокоили ущербность модели и инертность IETF, но один в поле не воин - тысячи разрозненных автоматизаторов по всему миру не могли ничего с этим сделать. А вот большие компании могли.

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

Могу только предположить, что в недрах гугла это происходило примерно так:

Вот была сеть из дюжины вендоров, были некие драйверы, которые могут доставлять конфигурацию на сетевые коробки. А ещё была где-то далеко стоящая база данных с переменными. А между ними 2 миллиметра антивещества.

Скорее всего, сначала появился некий дизайн сети, которые в суперпозиции с БД давал вендор-нейтральную конфигурацию.

Этот дизайн сети уже опирался на разработанную внутри модель данных - ведь в нём нужно было описать все нюансы конфигурации. То есть или уже была или параллельно с дизайном появлялась модель данных.

А вместе с тем набирал обороты gRPC. И на каком-то из удачно расположенных кофе-поинтов пересеклись парни из соседних отделов и подумали:

- Слышь, а зачем вам эти полумеры? Давай из вашей модели сразу же в коробку перекладывать? Мы вам поможем агента написать

- Да, но у нас циски, проприетарная ось.

- Да это фигня. О, Джон, здоров. Давай парням линукс на свитчи вкорячим?

- Так давай, изян. Через сколько месяцев надо?

- Подождите, подождите, там типа чип, SDK, памяти маловато

- Хей, Рони, алло! Нам нужен свитч, на который мы можем свою операционку поставить

- Без базы, ща, в R&D запустим.

Ну как-то так я себе представляю рождение OpenConfig.

OpenConfig - мечта, становящаяся явью

Возможно, впервые за шестидесятилетнюю историю телекоммуникаций у нас появился шанс изобрести свой USB Type C. Представьте мир, в котором Cisco, Juniper, Nokia и Mikrotik настраиваются одними и теми же командами и это к тому же приводит к одинаковому результату?

Я не могу.

OpenConfig - это открытая YANG-модель, которая предполагается единой для всех вендоров. Одна стандартизированная модель для сбора операционных данных с устройств, управления конфигурацией и анализа телеметрии.

Итак, OpenConfig появился в Google, как они сами сказали на наноге в 2015, как ответ на следующие вызовы:

• 20+ ролей сетевых устройств
• Больше полудюжины вендоров
• Множество платформ
• 4M строк в конфигурационных файлах
• 30K изменений конфигураций в месяц
• Больше 8M OIDs опрашиваются каждые 5 минут
• Больше 20к CLI-команд выполняется каждые 5 минут
• Множество инструментов и поколений софта, куча скриптов
• Отсутствие абстракций и проприетарные CLI
• SNMP не был рассчитан на столь большое количество устройств и на столько большие объёмы данных (RIB)

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

Вскоре после этого в том же 2015м был сделан первый коммит в публичную репу openconfig/public.

Так начал своё шествие по индустрии OpenConfig.

Вот тут все модели данных, разработанные и опубликованные в OpenConfig.

Картинка побольше

Никаким стандартом он не стал, в RFC не превратился, но вендоры его подхватили. Ещё бы они его не подхватили - очень быстро к гуглу подтянулись и другие гиганты - за OC теперь топят десятки компаний.

Есть только пара проблем - карта старовата и некоторые ссылки на сайте ведут на 404 :)

Но репозиторий живёт насыщенной жизнью.

Есть и ещё пара проблем посерьёзнее, но о них в конце главы.

OpenConfig сегодня даёт возможность настройки стандартных сервисов, таких как интерфейсы, IP-адреса, NTP, OSPF и прочее. Безусловно, речь не идёт про вещи, завязанные на аппаратные особенности: QoS, управление буферами и ресурcами чипа, сплиты портов, работа с трансиверами. И в каком-то хоть сколько-то обозримом будущем этого ждать не стоит.

Хуже того, на сегодняшний день многие вендоры, ввязавшиеся в поддержку OC, не реализуют все 100%, а лишь часть - ту, которая нужна им, а точнее, их заказчикам.

Но BGP с OSPF настроить точно можно.

И что же делать, если брать 5 разных несвязанных Native-моделей не хочется, а OC-модель не покрывает всех необходимых функций?

И есть два пути.

Один из них - брать OC и видоизменять его с помощью добавления или убирания каких-либо его частей.

Когда вендор хочет расширить покрытие модели - он делает augmentation (расширение, дополнение), встраивая его в нужное место.

Если он хочет поменять какое-то поведение или удалить функционал - он описывает deviation (отклонение) к базовой модели.

Этот способ, конечно, не покрывает все потребности.

Другой - совмещать OC и Native. В целом рекомендуют (даже сами вендоры), использовать OC там, где это возможно, а где нет - прибегать к Native. Главное - не настраивать одно и то же с помощью разных моделей.

Источник: доклад на Cisco Live

Если вам всё ещё кажется, что так можно жить, то пришло время сказать, что разные вендоры, оборудование и даже версии ПО могут использовать разные версии OC-модели и быть не полностью совместимыми. Вам всё ещё придётся думать о том, что и куда вы деплоите.

OpenConfig входит в наш мир в ногу с gNMI, как это и задумывал Google.

Но в качестве транспорта может быть как gNMI, так и NETCONF и RESTCONF - это не принципиально, потому что OC - это только YANG-модель, которая далее может быть переложена уже хоть в XSD, хоть в JSON-схему, хоть в gRPC protobuf’ы.