АДСМ5. История сетевой автоматизации
Это первая статья — историческая ретроспектива технологий и интерфейсов автоматизации сети. Если хочется более практического разбора, я отсылаю читателя к статье-спутнику, в которой мы собираем лабу, дёргаем апишки, настраиваем коробки.
В этой же разбираемся, как мы оказались в том месте, где мы находимся, и куда ведёт нас этот путь. Практическую пользу вам принесут только обе прочитанные статьи. Вторая без первой будет непонятна. Первая без второй — беллетристика.
Когда началась история сетевой автоматизации?
С Ansible в 2018? С ним она явно получила ускорение благодаря безагентной природе.
Не. До него были голые языки на букву «P»: Python, Perl, PHP.
С NETCONF? Точно нет, CLI ещё мой дед парсил. А уж сколько expect’ов там поработало…
SNMP — вот что приходит на ум в качестве первого подхода — он родом из 90-х.
Однако как насчёт перехода от коммутации каналов к коммутации пакетов? Нельзя ли назвать динамическую сеть, не требующую мгновенного ручного вмешательства при обрывах, разновидностью автоматизации?
А первый декадно-шаговый искатель, разработанный Строуджером в 19-м веке и раз и навсегда избавивший мир от ручного труда телефонисток?
Да и в целом даже сам факт появления телефонных станций взамен почты, курьеров и гонцов?
Весь наш мир последние лет 300 безостановочно гонится за ускорением. Людей становится всё больше (Индия вон обогнала уже Китай), но их труд всё дороже (не в Индии). И в этом помогает автоматизация.
300 лет! Тем временем в сфере сетевых технологий сложилось мнение, что тут всё замерло, мы топчемся на месте, изобретая велосипеды. Но это лишь из-за того, что мы берём довольно короткий период времени и гораздо больший акцент делаем на текущем моменте, нежели на тенденции.
Как говорится, мы склонны переоценивать краткосрочные последствия и недооценивать долгосрочные.
Все статьи АДСМ
Источник: доклад на Cisco Live:
https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKNMS-2032.pdf
В этой статье посмотрим, сколько всего в эти 30 лет уместилось.
А уместилось немало.
Содержание
One CLI to rule them all
С начала времён и до сего дня.
Сегодня бумажные деньги — это артефакты уходящей эпохи. Мы не можем в одночасье от них отказаться — даже в самых прогрессивных странах, потому что есть ещё огромный хвост людей, не готовых перейти на безналичный расчёт.
Но купюры были естественным и незаменимым средством ещё лет 10 назад. Они пришли взамен монетам из золота и серебра, которые были естественны лет 300 назад. А те заменили собой натуральный обмен, который был естественным несколько тысяч лет назад.
Так и командная строка в своё время являлась совершенно естественным методом взаимодействия с сетевым железом. Вбивали же люди в nix’ах команды в терминал? Ну так и маршрутизатор — тот же nix.
Это самый понятный человеку-инженеру способ общаться с устройством.
Начал набирать команду, сделал табуляцию, посмотрел список доступных аргументов, продолжили. Возникла ошибка при выполнении — сразу же текст в терминале отображается — принимаешь меры. Понятно, удобно, интерактивно. Нет ничего лучше для интерфейса человек-устройство. Интерфейса, который сегодня стремительно теряет свои позиции в настройке сервисов.
И если в сфере серверов уже многие годы сумасшедшими темпами развивается RPC и IaC, то в области сетевых технологий всё как-то ни шатко ни валко. На самом деле на сегодняшний день ситуация немногим менее печальная, чем лет 15 назад.
Командный интерфейс (CLI) реализует императивный интерфейс. А мы во всех сферах стремимся к декларативности.
CLI может быть структурированным и логичным, как на Juniper. Может быть как на Cisco/Huawei/Arista. Он может поддерживать транзакции посредством коммитов, а может применять команды по мере их ввода.
Коммиты могут быть реализованы через подмену running конфигурации candidate, через применение только разницы между текущей и целевой или через последовательное применение введённых прежде команд.
Команды затем транслируются в вызовы какого-то внутреннего API, который может быть понятен и даже в каком-то смысле документирован (привет, Juniper) или представлять из себя чёрный ящик (йо, хуавэй, как жизнь?).
Но главная суть не меняется — если ты хочешь что-то настроить, ты подключаешься по ssh, вводишь команды — читаешь ответ, предпринимаешь дальнейшие действия. То есть максимально понятно для человека и абсолютно неудобно для взаимодействия машина-машина. Все эти приглашения, промпты, текстовые выводы, ошибки и предупреждения породили expect’ы, textfsm’ы, napalm’ы и триста способов заставить скрипт вести себя как человек.
Но самая главная проблема CLI — это фундаментальные различия в синтаксисе и семантике у различных вендоров. А порой даже в различных версиях.
Не существует такого способа, который позволил бы декларативно объявить — хочу вот именно такую конфигурацию BGP с такими пирами и таким набором политик, и не хочу вычислять, что мне нужно для этого добавить, а что удалить.
И кроме всего прочего долгое время не существовало надёжного инструмента доставки и применения конфигурации — каждый изгалялся в меру своей фантазии.
Спасибо Майклу Дехану, вендорам и сообществу, попытка создать такой инструмент была предпринята — Ansible. Да, к нему много (у кого-то очень много) вопросов. Да, он не решает большей части проблем, озвученных выше. Но по факту это лучший опенсорсный инструмент для применения конфигурации на сетевое железо (ну, кроме Nornir), и Ansible — спасение для многих сетевых инженеров. Сложить весь прод одним нажатием Enter никогда прежде не было так просто.
Ещё одна особенность CLI — отсутствие контроля состояния. CLI делает то, что ему сказали. Если ты не побеспокоился о том, чтобы удалить лишнего пира специальной командой — он и не почешется. Контроль состояния — ответственность инженера.
С другой стороны CLI — это на сегодняшний день (и долго ещё так будет) единственный вариант, который на 100% современных железок позволит настроить 100% предоставляемой ими функциональности.
Учитывая, что компаний, которые сейчас строят сеть с нуля и могут выбрать только то оборудование, которое поддерживает полноценный NETCONF/gNMI, очень и очень немного, всем остальным нужно уметь поддерживать зоопарк оборудования разного возраста и уровня.
Собственно в Яндексе именно тем, что CLI работает в буквальном смысле на всём, и воспользовались. Аннушка настраивает сетёвку именно через CLI.
Что можно утверждать однозначно — CLI как таковой никуда не денется никогда. Даже в эпоху полностью автоматизированных сетей, командная строка никуда не уйдёт из сферы диагностики.
Он, возможно, будет глубоко запрятан, или он трансформируется в полноценную линуксовую консоль, но как средство управления он останется.
Однако факт того, что все способы автоматизации чего-либо через CLI — это попытка написать скрипт, который будет прикидываться человеком и предугадать все возможные исключительные ситуации и варианты ответа операционной системы, заставляет писать очень изощрённые программы и постоянно их адаптировать под изменяющееся от версии к версии поведение и синтаксис новых вендоров.
А сколько радости представляет как крафтинг, так и парсинг текста, вы можете представить.
Желание унифицировать подходы и сделать стандартизированным интерфейс взаимодействия появилось не вчера. О нём думали уже в 80-е, что и породило очень удачное решение — SNMP.
SNMP — и не simple, и не management, и не short term
Бунтарские 80-е — лихие 90-е.
Это была достаточно смелая и, в некотором смысле, успешная попытка создать единый стандарт взаимодействия с сетевым устройством.
В 80-е годы было уже вполне понятно, что сети — бурнорастущая отрасль, в которой уже сейчас хаотически складываются подходы к управлению.
И вот умники в IAB (Internet Activities Board) крепко призадумались и 21-го марта 1988 года, собравшись в тогдашнем зуме (без шуток, не офлайн), постановили много важного стратегического про будущее систем управления интернетом. Ох они тогда напридумывали!
Результаты встречи они сели, записали и превратили в RFC1052.
Они уже тогда действительно проектировали штуки, которые должны были не дать превратиться системам управления в то, во что они всё же превратились.
Как иронично теперь читать это послание из 80-х:
(i) Future Internet development is a joint interest of the R&D
community, the vendor community and the user community.
(ii) We still don't have a common understanding of what
[Inter]Network Management really is.
(iii) We will learn what [Inter]Network Management is by doing it.
(v) Define the Management Information Base for TCP/IP suite NOW!
(vi) Seek a seat for IETF on ANSI, ISO and/or CCITT
Удачи вам там, пацаны, в будущем… Но работа закипела. RFC выходил за RFC. А количество рабочих групп не оставляло шансов для провала.
Что любопытно, так это то, что SNMP по их задумке был временным протоколом, решающим насущные нужды вендоров и операторов в перспективе нескольких лет. А в дальнейшем все должны были перейти на ISO CMIP/CMIS (RFC1095 и RFC1189). Общими для них оставались MIB (RFC1066) — спецификации, описывающие формат данных.
Уверен, что уже тогда не всем эта идея пришлась по душе.
В те дни человечество ещё верило в ISO.
CMIP/CMIS — Common Management Information Services/Common Management Information Protocol — это такая же несостоявшаяся вещь, как OSI. Здорово всё напланировали, но временный SNMP заполонил всю планету.
Есть и другие слова, выдуманные в те дни, которые мы сейчас нигде в обиходе не используем: HEMS, SGMP, NETVIEW, TNM, LANMANAGER, Network Computing Forum «Fat Document»…
SNMP именно потому и был Simple, что на горизонте маячил Common. И его планировали держать «Simple», пока не откажутся. А вовсе не потому что он сам по себе был прост. Кажется, нам, как цивилизации, ещё повезло, что на смену SNMP не пришло что-то не столь Simple.
Итак, SNMP победил, если это можно считать победой. А другие рабочие группы распустили.
MIB — являл собой спецификацию, говорящую как системе управления, так и сетевому устройству, как собирать и интерпретировать SNMP-сообщения.
То есть на одной стороне есть инструкции того, как собрать пакет, на другой — как его прочитать. Остаётся только подставлять переменные и посылать через SNMP.
Ну какова красота?! Никакого чтения документации, никакой человеческой интерпретации — только строгое следование спецификации. И это начало 90-х!
Скажу вам больше — те же парни из IAB, ещё до того, как Cisco начала паровозить тему с SNMP, придумали SMI — Structure of Management Information — по сути язык моделирования данных — то, как именно данные будут структурированы в MIB.
Для нас не очень важно что и в течение какого времени нужно употреблять, чтобы написать и прочитать написанные на языке ASN.1 модели SMI. Для нас важно, что SMI дал жизнь YANG'у. Всё же не вся работа тогдашних групп была в стол. Но об этом позже.
Уже тогда, в 90-е, все хотели сделать что-то универсальное и отвязаться от вендорской специфики, но настойчивых попыток не предпринимали, а вендоры в погоне за time to market были ещё меньше заинтересованы вкладываться в стандартизацию того места, где им не придётся стыковаться друг с другом. Поэтому единой модели тогда не появилось.
Однако теперь следите за руками: к концу 90-х у нас уже были:
Протокол — SNMP;
Спецификации — MIB;
Язык их моделирования — SMI;
Возможность стримить данные с железки на NMS — Trap’ы (ну серединка на половинку, конечно, но всё же);
Целая пачка инструментов, утилит и NMS, работающих с MIB и SNMP — snmpwalk, MIB browser;
Желание вендоров поддерживать это и выпускать MIB’ы для каждой новой версии вовремя.
По всей видимости мы были просто в шаге от дивного мира с единым фреймворком для сетевой автоматизации.
Но добавляя ещё один пункт:
мы получаем ситуацию, в которой мы находимся прямо сейчас. Та-дам!
Но даже без этого в силу сложности (S for Slozhnost), вопросов к архитектуре, безопасности, транзакционности, нечитаемости спецификаций, непрогнозируемости результатов, невозможности проиграть изменения повторно, UDP в качестве транспорта и многим другим, SNMP нашёл применение лишь в задачах сбора данных с сетевых устройств и в крайне вырожденных случаях для настройки точечно тех или иных вещей.
Впрочем сегодня даже в вопросах мониторинга SNMP скромно уступает место NETCONF и gNMI.
Смахнули скупую слезу и забыли! И про SNMP и про CMIP/CMIS. Не забываем только про SMI.
Переходим к современности.
API
Давайте на парсек поднимемся над нашей ежедневной рутиной и взглянем на сеть с расстояния. И тогда можно увидеть, что программную работу с сетевым оборудованием следует рассматривать как взаимодействие с удалённой системой (чем она и является). А уже много лет назад для этого придумали термин — API.
То есть, если мы хотим чего-то от этой системы, мы используем известный интерфейс, для которого описано, как и что мы должны сделать, чтобы добиться желаемого результата. API — это широкий и абстрактный термин, сам по себе не говорящий ничего о схеме данных, о формате и протоколах взаимодействия — просто программный интерфейс приложения — не человеческий, а программный.
И под одним этим зонтичным термином скрываются совершенно разные виды:
Хотя никто его так и не называл
Одни из них, такие как REST оперируют ресурсами и представляют набор операций над ними, в случае REST: CRUD — Create Read Update Delete. То есть вы можете создать (Create) ресурс «билет на linkmeetup» и скачать (Read) его далее в любой момент. С REST мы уже разбирались как-то.
Другие виды API оперируют функциями, и позволяют на сервере запускать те или иные оговоренные программы. К последним относится класс API, который можно назвать RPC.
RPC — Remote Procedure Call
Этот термин родом из языков программирования. Ещё на рубеже 50–60-х годов языки вроде Fortran II и ALGOL ввели в обиход разработчиков процедуры (они же функции). С тех пор они везде — большинство языков — процедурные. Любое действие — это вызов процедуры — Procedure Call. И когда-то эта процедура должна была находиться где-то в том же модуле или в соседних, но точно рядом и в том же окружении. Но почему бы не слать вызов с параметрами на удалённую машину, где мы хотим что-то выполнить?
Например, мы могли бы по HTTP/FTP скачать несколько гигов данных sFlow с сервера и проанализировать их локально, а можем отправить сигнал на сервер, чтобы сложную статистику вычислил он сам и вернул результаты в ответе. Так вот второе — это удалённое исполнение кода.
Анналы истории говорят, что в в 1981 году Брюс Джей Нельсон, работая в Ксероксе, изобрёл концепцию и термин RPC — Remote Procedure Call.
RPC — удивительный клиент-серверный механизм, который позволяет запустить исполнение кода процедуры на другой машине так, словно бы он исполнялся локально. То есть разработчик просто привычным образом обращается к процедуре, не задумываясь о том, где и как она исполняется — главное, чтобы она вернула ответ. А программа уже сама реализует взаимодействие с удалённой машиной.
Прелесть этого подхода в том, что он, во-первых, позволяет скрыть удалённый характер работы. А, во-вторых, на той, другой, стороне совершенно неважно, какая операционная система, архитектура, язык программирования и окружение — главное, чтобы они подчинялись одному протоколу.
Можно провести аналогию с TCP — не важно, какие операционные системы на хостах, желающих друг с другом общаться, — важно, чтобы они следовали спецификациям протокола TCP и его конкретной реализации — и тогда данные, отправленные одним хостом, будет возможно интерпретировать на другом.
Так в случае RPC, из-под винды в питоне, например, вы можете исполнить удалённую программу, написанную на Go, запущенную на линуксе. И никто вам не сможет помешать!
Но что, по большому счёту, мы делаем, когда, зайдя по SSH, выполняем какую-то команду на коммутаторе или маршрутизаторе? Запускаем определённый код.
Например, сообщаем подсистеме BGP, что нужно теперь пробовать установить соединение с новым пиром.
Только представьте, как было бы восхитительно, если бы для вызова этого кода, не нужно было заходить на железку по SSH и вбивать команду?!
Взаимодействие между приложениями через RPC используется преимущественно в условиях, когда требуется обеспечить тесную связь между ними, когда они все формируют единую систему.
В то же время REST API наоборот требуется, когда компоненты должны быть достаточно изолированы и развиваться независимо.
Так REST обычно предоставляют внешним клиентам, B2B, смежным, но малосвязанным командам. Например, публикация постов в соц.сетях или агрегаторы авиабилетов при обращении к сервисам авиакомпаний. А RPC — там, где компоненты составляют часть чего-то большего, например, узлы банковской системы или микросервисные архитектуры.
В целом RPC — это концепция, не говорящая ничего о реализации. Она постулирует, что на стороне клиента есть так называемый стаб (stub) — фрагмент кода, который реализует взаимодействие по RPC. Именно стабы делают для разработчика прозрачным вызов функции — из приложения вызывается этот стаб с набором параметров, а уже стаб делает удалённый вызов.
Ключевая часть RPC — спецификация — штука, которая на стороне сервера и клиента определяет, как работать с данными — как упаковать, как распаковать. Без участия человека, конечно же.
Язык, на котором пишется спецификация — IDL — Interface Definition Language. Иными словами, на IDL пишется спецификация, на основе которой создаются и серверный интерфейс, и клиентский стаб. Это может быть, например, набор классов в питоне, имеющих функции для удалённого вызова, с которыми разработчик работает так, словно всё происходит локально — для клиента. И набор объектов Go — для сервера.
Наевшись с CLI и SNMP, сетевики придумали два протокола, которые используют под капотом RPC и при этом позволяют управлять сетевым железом:
NETCONF
gRPC
NETCONF
Сытые 0-е и по ныне
Если вам по какой-то причине кажется, что стандарты рождаются где-то в недрах институтов, оторванных от жизни, то послушайте вот эту историю. Скорбно при этом помним про ISO.
В 1996 выходец из Ксерокса Прадип Синдху и Скот Кринс из StrataCom, купленной Циской, основали Juniper Networks. Идея создания мощного пакетного маршрутизатора пришла в голову Синдху, и он стал CTO компании, а второго наняли на роль CEO.
Источник: https://tofactorydefault.files.wordpress.com/2013/12/juniper-m40.jpg
Вместе они создали легендарный М40 и лучший в мире интерфейс командной строки. До сих пор никто не сделал ничего лучшего — все только повторяют. Операционка, предоставляющая клиенту обычный текстовый интерфейс, на самом деле перекладывает команды в XML, который используется для управления оборудованием…
Так вот, их CLI и способ взаимодействия его с системой оказался настолько естественным и удачным, что его и положили в основу стандарта NETCONF в 2006-м году. Не без участия Juniper Networks, конечно же, появился RFC4741. Будем честны, один только джунипер там и постарался в практической части. И то тут, то там будут проскакивать его куски, начиная с set и заканчивая candidate config.
Вот как он был определён в нулевых:
Abstract
The Network Configuration Protocol (NETCONF) defined in this document
provides mechanisms to install, manipulate, and delete the
configuration of network devices. It uses an Extensible Markup
Language (XML)-based data encoding for the configuration data as well
as the protocol messages. The NETCONF protocol operations are
realized on top of a simple Remote Procedure Call (RPC) layer. И определение с тех пор не менялось — вся суть NETCONF в этом параграфе.
Но как так получилось, с чего началось? Да с того, что в начале 2000-х IAB проснулся в одно недоброе утро и осознал, что все планы по CMIP мир провалил, SNMP прорастил свои корни глубоко и перестал быть Simple, никто из вендоров так и не реализовал на 100% его поддержку, в самой аббревиатуре SNMP «M» вместо «Management» стала обозначать «Monitoring», и к тому же единой модели данных конфигурации не получилось. Хуже того — появился этот выскочка Juniper, который везде суёт свой нос.
В общем умники из IAB крепко призадумались. И собрались снова — на этот раз в офлайне 4-го июня 2002-го года в Рестоне (это в Штатах — любопытный городок — почитайте), чтобы «продолжить важный диалог, начатый между операторами и протокол-девелоперами».
Сели, похаяли SNMP, покекали с аббревиатур COPS, SPPI, PIB, CIM, MOF и записали это всё в тик-ток RFC3535.
Выхлопом этой встречи стали 33 наблюдения и 8 рекомендаций. Среди них есть действительно важные, определившие наше настоящее.
1. Программные интерфейсы должны предоставлять полное покрытие,
иначе они не будут использоваться операторами, поскольку они
будут вынуждены использовать CLI.
5. Необходимо строго разделение между конфигурационными и операционными
данными
8. Необходимо иметь возможность выгрузить и загрузить конфигурацию
в текстовом формате в единообразной манере между всеми вендорами
и типами устройства
9. Желательно иметь механизм доставки конфигурации в условиях
транзакционных ограничений.
14. Необходимо, чтобы устройства поддерживали как программный,
так и пользовательский интерфейс
15. Внутренние операции на устройстве должны быть одинаковы
как для программного, так и для пользовательского интерфейсов.
26. Должна быть возможность произвести операцию над указанной секцией
конфигурации.
27. Должна быть возможность выяснить возможности устройства
28. Необходимы безопасный транспорт, механизмы аутентификации
и авторизации, поддерживаемые текущей инфраструктурой.
30. Полная конфигурация устройства должна быть применима через один
протокол.Часть из них мы воспринимаем сегодня как самоочевидное, мол, а как вы ещё иначе могли бы такое сделать? Но это не воспринималось так тогда. Просто вспомним как устроен SNMP:)
А ещё были явно полезные рекомендации:
Рабочее совещание рекомендует прекратить форсить рабочие группы предоставлять конфигурационные MIB’ы;
Рабочее совещание рекомендует не тратить время на CIM, COPS-PR, SPPI PIB.
В общем-то какие претензии к SNMP и его компании заставили уважаемых людей собраться на три дня?
Проблемы масштабирования. Забирать большие объёмы данных с большого количества устройств он не был рассчитан.
Транзакционность изменений на устройстве, и тем более на сети, должна была поддерживаться не протоколом и устройством, а системой инструментов.
Откат также лежал на инструментах.
Writable MIB не покрывали большей части задач по настройке устройства.
Весь этот куст OID’ов был крайне сложночитаем для человека. Понять, что произойдёт после работы скрипта было очень сложно. Сколькие из вас отчаялись, пытаясь его понять?
Не было никакого инструмента, который позволял бы повторно выполнить те же действия идемпотентно на этом же устройстве или на другом.
Контроль состояния тоже отсутствовал.
В итоге протокол, призванный решать вопрос автоматизации, не особо-то для этого подходил. Короткий итог встречи: IETF всё это время что-то там придумывал, разрабатывал, чтобы сделать жизнь операторов проще, а те не будь дураками, пришли и наконец сказали, что, мол, вы тут штаны просиживаете, а ничего полезного для нас не делаете, а делаете вы бесполезное! И ISO туда же!
И в этот момент Juniper из-за угла приоткрывает полу своего XML-API. И он оказывается настолько более лаконичным (это XML-то!) и удобным, что рабочая группа внезапно решает принять его концепции в качестве стандарта NETwork CONFiguration protocol — RFC4741 . Упор на Configuration в названии — это, видимо, гиперкомпенсация отсутствия режима конфигурации в SNMP.
Вот так в итоге скромно упомянут джунипер в этом RFC:
In the late 1990's, some vendors started to use the Extensible Markup
Language (XML) [XML] for describing device configurations and for
protocols that can be used to retrieve and manipulate XML formatted
configurations.А через 5 лет, в 2011, исправленное и дополненное издание вышло под номером RFC6241. Там уже потрудились несколько университетов и компаний. Одной из них стала восходящая звезда сетевой автоматизации Tail-f, купленная и погубленная в 2014-м году циской.
И вот в операторские сети на белом коне въезжает NETCONF.
Работает по SSH (и не только),
Представляет данные в структурированном виде,
Разделяет конфигурационные и операционные данные,
Имеет несколько операций над данными: create, merge, replace, delete, remove,
Может обеспечить контроль целевого состояния конфигурации,
Поддерживает концепцию нескольких версий конфигурации (datastores),
Может поддерживать commit конфигурации. Обеспечивает транзакционность,
И вообще красавчик.
Причём Juniper его поддерживает с нулевого дня. И в полной мере, потому что для него это максимально естественно — это и есть его API. А вот внутренний API той же Циски или Хуавэя не ложится так гладко на XML и какую-либо простую схему. Для них поддержка NETCONF — это большая работа, которую они выполняют с переменным успехом. Коммиты, операция replace — это всё даётся тяжело. А именно в них вся сила.
Datastores — это различные версии конфигурации на устройстве: running, candidate, saved и, возможно, другие. Они позволяют не менять на лету работающую конфигурацию.
Commit обеспечивает три буквы ACID — Атомарность, Консистентность и Изолированность.
Операция Replace — мощнейшая штука — позволяет заменять всю или часть конфигурации на новую.
Мы привыкли, что в CLI нам нужно сформировать список команд, добавляющих новую конфигурацию, и команд — удаляющих старую — ненужную. Довольно простая операция для человека, но чудовищно сложная для автоматики. Мы настолько привыкли, что это даже не вызывает раздражения у нас. А с NETCONF replace — мы просто суём ту конфигурацию, которую хотели бы видеть, а коробка сама считает, что нужно сделать, чтобы к ней прийти из текущего состояния. Это и есть тот самый декларативный путь, к которому мы так стремимся.
Для работы с NETCONF есть библиотеки для питона (и синхронные, и асинхронные), для го, плагины для Ансибл. Вроде бы всё — бери и пользуйся. Но не все производители его поддерживают. И совсем немногие поддерживают его в полной мере. Где-то нельзя настроить DHCP-Relay, где-то нет секций IPv6-vpn AF в BGP, где-то replace не поддерживается или поддерживается, но работает через delete/create — ух, неспасибо за это.
В итоге пара пунктов из вышеупомянутого RFC3535 нарушены: не всё можно настроить через этот новый протокол, а для настройки всех возможных функций нужен как минимум CLI.
Но своё место NETCONF уже прочно занял и будет дальше только расширять и углублять. Несколько вендоров действительно его поддерживают в полной мере. А на других точечные операции всё равно многократно удобнее через программный интерфейс со структурированными данными выполнять. Плюс своё давление оказывают крупные заказчики, требующие его.
RESTCONF
Буйные 10-е и забыли
The workshop recommends, with strong consensus from the operators
and rough consensus from the protocol developers, that the
IETF/IRTF should not spend resources on developing HTML-based or
HTTP-based methods for configuration management. RFC3535. Recommendation 6.
SSH — это хорошо. Но на сетевую автоматизацию случился спрос, а за ним наплыв сил разработчиков. А вот эти разработчики хорошо шарят в REST, но на курле крутили все эти наши SSH и парсинг текста. В компаниях, где начинают заниматься автоматизацией сети, обычно уже есть свой штат разработчиков, инструменты, практики. И они в лучшем случае рассматривают сеть, как ещё одни сервера, а то и ещё один сервис.
И вот REST API с CRUD им очень знаком.
Вот и решили парни из циски, джунипера и tail-f: «а почему бы не запилить REST API в сетевые коробки?». Ну пошли и запилили — делов-то. И назвали RESTCONF — всё ещё отзываются боли SNMP.
Драфт был опубликован в 2014-м, а в 2017 мир увидел RFC8040.
Это помесь RESTAPI и NETCONF, которая была призвана упростить управление сетью для WEB-приложений.
Внутри идеологически это NETCONF с его datastores и способами работать с конфигурацией, однако в качестве транспорта — HTTP с набором операций CRUD, реализованных через стандартные методы (GET, POST, PUT, PATCH, DELETE).
Конфигурационные данные передаются в формате JSON или XML. В качестве модели данных используется только те, что написаны на языке YANG — тут уже никакой самодеятельности.
С самого начала RESTCONF не затевался как замена NETCONF, а только как более удобный для WEB-приложений способ работать с сетевыми устройствами. То есть они должны сожительствовать. При этом обычно на устройстве реализуется один бэкенд, обрабатывающий запросы на работу с конфигурацией и опер.данными от разных фронотов — NETCONF или RESTCONF. То есть в основе одни и те же datastores, один и тот же движок, вычисляющий конфигурационные дельты, но сложность транзакционности и нескольких разных видов конфигураций (running, candidate, saved) от пользователя скрыта в случае NETCONF.
С другой стороны отсутствие в выдаче поисковиков хоть сколько-то серьёзных работ по автоматизации с помощью RESTCONF и даже популистских статей от больших игроков говорит о том, что это всё не более чем баловство. И я намеренно не пишу слово «пока». Лично я в него не верю.
При этом CRUD не очень гладко ложится на RPC-подход, да и в идее держать открытым на сетевом железе HTTP есть что-то противоестественное, согласитесь? Нет? Ну ладно.
Просто жаль сил, вложенных в этот протокол. Потому что на пятки ему наступает gRPC/gNMI
Однако вернёмся к 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-модель через операцию
Пусть говорят:, но универсального пути тут нет, увы.
Главное: с этим уже можно было жить. Инженерам стало нужно чуть меньше думать об интерфейсах и форматах сообщений, но с глубоким вниманием подходить к содержимому сообщений всё ещё приходилось, оказывая разные знаки почтения разным вендорам.
При этом казалось бы — вся сеть — это конечный набор одинаковых сервисов, если выбросить всякие IGRP, HSRP, RRPP и прочие проприетарные выдумки. Ну, всем же нужен IP, OSPF, BGP? Всем нужна аутентификация на устройствах и SSH? Они не могут иметь очень уж принципиальные отличия, как минимум из-за необходимости поддерживать сов
