Привет! Я — Борис Хасанов, ведущий сетевой архитектор в MWS, а это продолжение моей статьи о телеметрии, начало можно изучить здесь. В этой части разберём основы сетевой телеметрии, её виды, протоколы и модели.
Как сетевая телеметрия помогает собирать данные
Любая новая технология призвана решить какие-то проблемы и преодолеть недостатки предыдущих, работавших в определённой области. Коротко отмечу основные недостатки традиционных механизмов сбора информации с сетевых устройств:
Используется poll-модель с периодическим опросом, что не обеспечивает сбор данных в приближенном к реальному времени формате, и, соответственно, имеется нехватка точности в собранных данных
Нет формальной модели данных, ярким примером могут служить различные вендорские SNMP MIB
Очень ограниченная поддержка push-нотификаций (SNMP trap, syslog, который надо парсить, sFlow — сэмплированные пакеты)
Существенная загрузка ЦПУ при опросах со всеми вытекающими последствиями
Как ответ на перечисленные выше ограничения и недостатки индустрия предложила сетевую телеметрию. Что это такое? Во-первых, это дальнейшее расширение и дополнение архитектуры ОАМ, про которую я рассказал в предыдущей статье. Во-вторых, если пытаться дать формальное определение, то можно сказать, что сетевая телеметрия — это процессы и инструментарий для получения и утилизации данных о состоянии сети для её мониторинга и управления.
Основные техники, которые используются в сетевой телеметрии:
Push и стриминг вместо традиционного опроса (polling) — идея заключается в том, что коллекторы телеметрических данных подписываются на нужные данные (сенсоры), которые устройство начинает передавать непрерывно (пока активна подписка)
Объём и быстрота — данные телеметрии предполагается собирать со многих источников (сенсоров), соответственно, их объём может быть в разы, если не на порядки, больше текущих, соответственно, нужна их быстрая обработка
Нормализация и унификация — приведение различных данных (протоколов, устройств) к общему формату
Модельно-ориентированная — данные телеметрии отправляются согласно заранее определённой модели, что существенно облегчает их обработку
Корреляция данных от различных источников
Динамичность и интерактивность — данные для автоматизации управления сетью отправляются непрерывно, кроме того, отправка должна адаптироваться к изменениям в запросах (подписках)
Архитектурный концепт сетевой телеметрии предлагает следующее разделение сетевой телеметрии на несколько логических сущностей:
Итак, в зависимости от того, где располагаются источники данных для телеметрии (сенсоры) и откуда будет осуществляться их экспорт, сетевая телеметрия делится на четыре основных модуля:
Телеметрия плоскости менеджмента (management plane)
Телеметрия плоскости управления (control plane)
Телеметрия плоскости пересылки данных (forwarding plane)
Телеметрия от внешних источников
Чтобы облегчить понимание свойств различных вариантов сетевой телеметрии, RFC 9232 сравнивает их по шести различным параметрам:
Объект данных — источник данных для каждого модуля телеметрии
Локация данных — ASIC/NPU, ЦПУ и т. п.
Модель данных — например, на основе языка Yang
Кодирование данных — JSON, XML, GPB
Протокол для телеметрии — Netconf, gRPC, BGP
Метод транспорта данных — TCP, UDP
Для удобства это сравнение сведено в таблицу:
Модуль телеметрии | Телеметрия плоскости менеджмента | Телеметрия плоскости управления | Телеметрия плоскости пересылки данных | Телеметрия от внешних источников
|
Объект данных | Конфигурационное и эксплуатационное состояния устройства | Состояние протоколов (маршрутизация, сигнализация) и RIB | Статистика: трафик, состояние буферов и очередей, QoS, ACL, FIB | Различные данные (н-р, accounting, состояние устройства, алармы и т. п.) |
Локация данных | ЦПУ | ЦПУ, ЦПУ на линейной карте | ASIC/NPU, ЦПУ на линейной карте | Различные варианты |
Модель данных | Yang, MIB, syslog | Yang либо кастомизированный вариант | Yang либо кастомизированный вариант | Yang либо кастомизированный вариант |
Кодирование данных | GPB, JSON, XML | GPB, JSON, XML, текст | GPB, текст | GPB, JSON, XML, текст |
Протокол для телеметрии | gRPC, Netconf, Restconf | gRPC, Netconf, IPFIX, BGP, зеркалирование трафика | gRPC/gNMI, sFlow, IPFIX, зеркалирование трафика и др. | gRPC и др. |
Метод транспорта данных | HTTP(S), TCP | HTTP(S), TCP, UDP, QUIC (в будущем) | UDP, TCP, QUIC (в будущем) | HTTP(S), TCP, UDP |
Виды телеметрий
Сейчас расскажу подробнее о перечисленных выше видах сетевой телеметрии.
Телеметрия плоскости менеджмента
Телеметрия плоскости менеджмента сетевого устройства взаимодействует в первую очередь с NMS (возможно, что и с BSS), в которую передаются данные о состоянии устройства (сбои, алармы, температурные параметры, утилизация компонентов, производительность, логирование, статистика и т. д.) посредством различных протоколов, включая традиционно любимые сетевыми инженерами SNMP и syslog.
Независимо от типа протокола, нам нужно:
Иметь возможность подписки на те данные, которые нам нужны, возможность задавать, как часто мы хотим получать эти данные
Иметь структурированные данные с прицелом на автоматизацию их получения, например при помощи языка моделирования Yang структурировать данные, повысить эффективность их кодирования и обработки
Повысить скорость отправки данных, например перейдя от традиционного режима опроса к режиму подписки
В этой статье я фокусируюсь только на телеметрии плоскости управления и плоскости пересылки данных.
Телеметрия плоскости управления
В первой части статьи я подробно описал архитектуру ОАМ и её компоненты и протоколы, такие как BFD, TWAMP/TWAMP-Light, STAMP. Один из основных их недостатков заключается в том, что они измеряют определённые KPI (потери пакетов или IP-достижимость, задержку), которые не отражают статус работающих протоколов плоскости управления: например, протоколов динамической маршрутизации (ships in the night). Поэтому нам нужно иметь дополнительные инструменты или протоколы для того, чтобы получать состояние протоколов маршрутизации от маршрутизаторов — прошу прощения за тавтологию. Необходимо оценивать состояние плоскости управления (control plane) в квазиреальном времени. Было несколько практических попыток реализовать такую телеметрию.
Interface to the Routing System — i2rs
Одной из попыток такого рода в IETF была рабочая группа (WG) Interface to the Routing System — i2rs WG, в ней пытались описать абстракцию системы маршрутизации, интерфейсы для доступа к различным состояниям и метаданным. Результатом работы i2rs WG были документы о формулировке проблемы и описание архитектуры. К большому сожалению, из-за различных межвендорских противоречий и различий во взглядах эта WG прекратила свою работу. Но сама проблема никуда не исчезла.
BGP Monitoring Protocol (BMP)
Параллельно была предпринята другая попытка, теперь уже более адресная и конкретная — сделать телеметрию RIB, а также протокола BGP в виде отдельного протокола — BGP Monitoring Protocol или BMP. BMP c дальнейшими расширениями позволяет получать состояние:
— Adj-RIB-In (необработанную маршрутную информацию, полученную от BGP-пиров, её ещё называют pre-policy), Adj-RIB-Out (маршрутную информацию BGP, отправляемую соседям ⦋BGP-пирам⦌, служит для проверки исходящих политик), а также Local RIB — локальную маршрутную информацию, т. е. префиксы, выбранные в качестве наилучших локальным BGP-процессом.
Понятно, что для разных сценариев значимость статистики по тому или иному RIB будет разной, в общем случае нам может быть очень важно и интересно отслеживать состояние именно Local RIB, т. к. она влияет непосредственно на форвардинг трафика и поиск неисправностей или траблшутинга.
Как же работает ВМР? Во-первых, он работает по ТСР, стандарт не задаёт конкретного номера порта, поэтому имплементации ВМР позволяют сконфигурировать нужный. Во-вторых, он всегда односторонний — сообщения отправляются от маршрутизатора/коммутатора к коллектору.
ВМР использует следующие основные типы сообщений:
Route Monitoring (RM) — используется для передачи начального дампа всех маршрутов, затем для инкрементальной передачи апдейтов
Peer Down/Peer Up Notifications — сообщения, посылаемые в случаях падения или поднятия BGP-сессий
Initiation — средство для маршрутизатора информировать коллектор о версии софта, производителе и т. п.
Termination — средство для маршрутизатора информировать коллектор об окончании сессии
Route Mirroring — в этом сообщении маршрутизатор передаёт копии маршрутной информации от BGP-сессий
Активная или пассивная сторона для TCP-соединения устанавливается в конфигурации.
Тип сообщения | Значение |
0 | Route Monitoring |
1 | Statistics Report |
2 | Peer Down Notification |
3 | Peer Up Notification |
4 | Initiation Message |
5 | Termination Message |
6 | Route Mirroring Message |
Типы ВМР-сообщений
Таким образом, мы имеем три заголовка в ВМР-сообщении: Общий → Заголовок для каждого BGP-соседа → Заголовок самого сообщения (кроме Route Monitoring, где только два заголовка плюс набор TLV). Вот как это выглядит на практике:
Хочу также сослаться на интересный доклад Ивана Терентьева из OzonTech c конференции nexthop 2024 (доклад посвящён обзору и практическому применению ВМР для мониторинга фабрики ЦОД), а также на статьи коллег на Хабре, посвящённые этому же вопросу.
Ну и очень важный момент про то, почему ВМР очень хорош именно для телеметрии плоскости управления: имеются специальные статистические отчёты (Statistics Report, type 1), содержащие разнообразные, весьма полезные, счётчики, такие как:
Тип | Формат | Наименование |
1 | 32-битный счётчик | Number of (known) duplicate prefix advertisements |
2 | 32-битный счётчик | Number of (known) duplicate withdraws |
3 | 32-битный счётчик | Number of updates invalidated due to CLUSTER_LIST loop |
4 | 32-битный счётчик | Number of updates invalidated due to AS_PATH loop |
5 | 32-битный счётчик | Number of updates invalidated due to ORIGINATOR_ID |
6 | 32-битный счётчик | Number of updates invalidated due to AS_CONFED loop |
7 | 64-битный | Number of routes in Adj-RIBs-In |
8 | 64-битный | Number of routes in Loc-RIB |
9 |
| Number of routes in per-AFI/SAFI Adj-RIB-In |
10 |
| Number of routes in per-AFI/SAFI Loc-RIB |
11 | 32-битный счётчик | Number of updates subjected to treat-as-withdraw treatment |
12 | 32-битный счётчик | Number of prefixes subjected to treat-as-withdraw treatment |
13 | 32-битный счётчик | Number of duplicate update messages received |
14 |
| Number of routes in pre-policy Adj-RIB-Out |
15 |
| Number of routes in post-policy Adj-RIB-Out |
16 |
| Number of routes in per-AFI/SAFI pre-policy Adj-RIB-Out |
17 |
| Number of routes in per-AFI/SAFI post-policy Adj-RIB-Out |
Типы ВМР-счётчиков
Таким образом, помимо возможности «дампить» сами сообщения BGP (что в принципе делает ненужным традиционный подход в виде коллектора BGP, кроме некоторых особых случаев), BMP предоставляет нам массу интересной статистики по плоскости управления (control plane). Что также важно: протокол использует TLV (точнее, сначала не все сообщения поддерживали TLV, но сейчас сделано предложение добавить TLV в оставшиеся два сообщения) — он расширяем by design. Это видно по тому, что в него уже добавили поддержку Adj-RIB-out и Local RIB, а далее мы увидим, какие ещё возможности предлагается в него добавить.
Надеюсь, что читатель, который дошёл до этой части статьи, задаст справедливый вопрос: «А как же с практической частью, что с имплементациями BMP?»
Отвечу кратко — на сегодняшний день все известные вендоры в принципе поддерживают ВМР. Далее начинаются нюансы: на каком оборудовании, с какой версией ПО и в каком объёме (см., например, выше варианты поддерживаемых ВМР RIB и статистических отчётов, они дают имплементаторам широкое поле возможностей). Есть также и Open Source имплементации: FRR, BIRD, goBMP и так далее. Известные мне имплементации я свёл в таблицу:
Интересный вариант использования ВМР с собственным коллектором, как части другого продукта, предложили коллеги из Яндекса на nexthop 2024. Таким образом, если говорить практически про телеметрию плоскости управления, то стоит серьёзно рассмотреть именно ВМР.
Телеметрия плоскости передачи данных
IPFIX — стандартный вендоро-независимый механизм сбора телеметрии для плоскости передачи данных. После включения в него новых расширений (SR-MPLS, SRv6, информации об измерении задержки и др.) становится ещё более гибким.
В IPFIX активно добавляют новые расширения, это увеличивает области его применения, об этом поговорим отдельно. Альтернативным вариантом может быть sFlow — на мой взгляд, он менее функционален и динамичен, в этой статье я не буду на нём подробно останавливаться.
Следующим популярным и важным способом организации телеметрии плоскости передачи данных является gNMI-телеметрия, но к рассказу о ней, по-моему, нельзя приступать, не сделав краткий обзор Netconf/Yang и gRPC. Читатель, хорошо знакомый с этими технологиями, может его пропустить и перейти к следующей части — «gNMI и телеметрия плоскости передачи данных».
Обзор Netconf/Yang
У этой части статьи нет задачи сделать детальный обзор языка Yang и Netconf плюс gRPC, на эти темы есть множество источников, кроме того, рекомендую почитать выдержку из статьи «Автоматизация для самых маленьких», в которой автор понятно и с юмором рассказывает про историю появления Yang.
Краткое напоминание: Netconf — API, который используется для приёма и отправки конфигурационных наборов данных, используя RPC, которые клиент кодирует в XML (смотрите схему ниже) и отправляет серверу по защищённому соединению. Сервер отвечает также посредством XML, форматы запроса и ответа описаны в специальных XML-схемах, чтобы обе стороны могли их понять.
Netconf позволяет осуществлять полную конфигурацию устройства и может заменять собой традиционный CLI (что зачастую используется в NMS и SDN-контроллерах для автоматизации провижининга определённой конфигурации на устройства). Одно из значимых преимуществ конфигурации через Netconf — создание общей абстракции конфигурации, независимой от CLI разных вендоров (при этом необходима общая XML-схема, понятная разным устройствам, либо Yang-модель, см. ниже).
При начале сессии клиент получает поддерживаемые сервером Capabilities:
Хранилище (datastore) — суть версии конфигурации устройства.
</hello>]]>]]><?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>]]>]]>Пример Netconf hello
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
[SNIP]Пример ответного hello-маршрутизатора с capabilities
Тип Netconf операции (rpc) | Действие |
get | Получить действующий (running) конфиг и состояние устройства |
get-config | Получить весь конфиг либо его часть |
edit-config | Загрузить весь или часть конфига в определённое хранилище конфигурации |
commit | Команда устройству на имплементацию конфигурационных данных из хранилища для Candidate-конфигов |
copy-config | Копирование или замена данных в хранилище конфигов |
delete-config | Удаление хранилища конфигов |
lock | Блокировка хранилища конфигов на устройстве |
unlock | Разблокировка хранилища конфигов |
close-session | Мягкое закрытие Netconf-сессии |
kill-session | Форсированное закрытие Netconf-сессии |
Список Netconf-операций
Хочу обратить внимание на механизм нотификаций в Netconf, который представляет собой асинхронную отправку нотификаций сервером после того, как клиент подпишется на такие уведомления. Параметры подписки определяют, какие именно нотификации мы хотим получать от Netconf-сервера. Этот подход получил дальнейшее развитие в другом стандарте, задающем механизмы подписки на необходимые Yang-хранилища (datastores). Про дальнейшее развитие этого механизма я расскажу в части, посвящённой развитию Netconf.
Итак, Netconf реализует необходимый RPC функционал и может работать с XML- или Yang-моделью представления данных.
Как я говорил выше, одна из основных, необходимых сейчас для автоматизации, ключевых характеристик — это структурирование данных на основе определённой модели, на текущий момент, на основе языка Yang. Сейчас есть несколько мест, в которых разрабатывают различные Yang-модели, как сетевых элементов, так и сервисов, это:
Альянс OpenConfig (https://www.openconfig.net/ ) — создают публичные Yang-модели для сетевых устройств
IETF (www.ietf.org) — создают публичные Yang-модели для сервисов, протоколов
Broadband forum (https://github.com/BroadbandForum/yang) — публичные модели для сетей ШПД
Metro Ethernet Forum (MEF) — модели для Carrier Ethernet сервисов
Вендоры сетевого оборудования (делают приватные ⦋их ещё называют нативные⦌ Yang-модели, а также некоторые из них публикуют их или дают возможность получить их с устройства)
Другие (н-р, для контроллера OpenDaylight)
При этом некоторые вендоры, помимо своих приватных вендорских (нативных) Yang-моделей, поддерживают также и некоторые публичные Yang-модели. Например, какие-то OpenConfig-модели — это, естественно, делалось с прицелом на конфигурацию устройства. В таком случае пользователи оборудования могут использовать альтернативные — не вендорские варианты реализации сбора телеметрии с оборудования, а также его конфигурирования. Но, как обычно, заявленную поддержку надо обязательно тестировать.
Возвращаясь теперь к Yang-моделям, ещё раз отмечу, что первоначальный фокус их применения был именно конфигурационным — как запровижионить те или иные настройки сетевого элемента либо впоследствии сервиса с NMS или SDN-контроллера. В случае телеметрии мы используем их для обратного — получения потока структурированных согласно модели данных от сетевого элемента.
Какие Yang-модели бывают
Стандарт RFC 8199 YANG Module Classification от 2017 года описывает классификацию Yang-моделей/модулей.
Нижний уровень — это Yang-модели сетевых элементов, следующий и более сложный — это уже модели сетевых сервисов.
В сетевой телеметрии мы фокусируемся на Yang-моделях для сетевых элементов — самый нижний уровень абстракции на схеме выше. Там же даётся классификация моделей по происхождению (стандартные, вендорские и пользовательские) и по отношению друг к другу:
Остановимся более подробно на наиболее распространённых и используемых типах моделей.
IETF Yang-модели
Они разрабатываются различными рабочими группами Инженерного совета интернета, фокус, конечно, на моделях протоколов (ISIS, OSPF, BGP, MPLS, TWAMP и т.д.), а также сервисов (L2/L3 VPN…). IETF-модели делятся на несколько видов:
экспериментальные
стандартные (статус IETF RFC)
черновики (статус IETF draft)
Модели в большей части разрабатываются вендорами, но операторы и пользовательские сообщества также участвуют и могут их использовать. Большой плюс в том, что в процессе разработки и обсуждения модели в IETF обсуждаются и решаются сразу вопросы по её применению и использованию в мультивендорных сетях.
Список моделей можно посмотреть по ссылке.
OpenConfig Yang-модели
Участники консорциума, в основном операторы и поставщики облачных услуг, разрабатывают эти модели. Фокус — на модели сетевых элементов и устройств для провижининга конфигурации и получения состояния. Итак, ключевые свойства моделей OpenConfig:
Ориентированы на устройства
Вендор-независимы
Публичны (Open Source)
Имеющиеся варианты OpenConfig-моделей можно посмотреть тут.
При взаимодействии с вендором нужно не просто спросить: «Поддерживаете ли вы Yang?», а уточнить: «Какую версию языка Yang поддерживаете и какую кодировку? Какие модели поддерживаете? Какие публичные модели поддерживаются и насколько они закрывают соответствующий функционал оборудования? и так далее».
Разумеется, что у использования как публичных (Open Source), так и приватных вендорских моделей есть свои плюсы и минусы, я попытался свести их в таблицу (разумеется, отнюдь не полную и составленную исключительно по моему частному мнению):
Функционал | Вендорские приватные модели | Публичные (OpenConfig, IETF и т. д.) |
Применимость на оборудовании абстрактного вендора Х | 100%, если это вендор Х, 0%, если это вендор У | Скорее всего, будут закрывать только часть доступного функционала у вендора Х, с большой вероятностью потребуется доработка |
Зависимость от версий оборудования и ПО | 0%, если модель сделана под конкретную версию ПО и оборудования вендора Х, существенная вероятность проблем, если она сделана для более старой или более новой версии ПО вендора Х, которые потребуется решать через техподдержку | Формально зависимости нет, но на практике она, очевидно, будет, также потребуется доработка |
Объём использования Yang и дополнительных абстракций | Т. к. у вендора Х модель будет привязана к определённому оборудованию и/или версии ПО, то вероятна минимизация использования дополнительных абстракций и конструктов Yang | Т. к. публичные модели не знают друг о друге и о деталях имплементации, то будут вынуждены использовать большее кол-во конструктов Yang и абстракций |
Зависимость от вендора | 100% (полная), вендор всё решает сам и сам устанавливает приоритеты по добавлению новых моделей или функционала. Пользователь лишь может просить о добавлении нужных ему моделей в роадмапе | Минимальная (не могу сказать, что нулевая, — см. предыдущие строки). Пользователь обладает большей свободой и гибкостью в выборе модели (н-р, IETF или OpenConfig), но и несёт большую ответственность за результат |
Что же использовать? | Думать и решать исходя из вашего конкретного случая. Нет общего рецепта на все случаи | Думать и решать исходя из вашего конкретного случая. Нет общего рецепта на все случаи |
Эмпирическое сравнение «происхождения» Yang-моделей
Обзор gRPC-модели
gRPC
Выше мы кратко разобрали первоначальный вариант организации RPC на основе Netconf для управления конфигурацией устройства. Теперь же нам надо рассмотреть вариант организации RPC для сетевой телеметрии. Интуитивно я думаю, что нам теперь понятно отличие требований к управлению конфигурацией от требований для передачи телеметрических данных (множество потоков, больший объём данных, квазиреальное время) — соответственно, стало понятно, что для таких целей, по-видимому, нужно попробовать какой-то иной вариант RPC. Искать долго не пришлось — уже достаточно давно разработан и используется для коммуникации между сервисами gRPC — generalized Remote Procedure Call, выпущенный ещё в 2015 году как Open Source RPC framework. gRPC отличается масштабируемостью, производительностью и функциональностью.
Несколько основных преимуществ gRPC:
Эффективность для взаимодействия процессов — используется бинарный протокол для коммуникаций (Protobuf через HTTP/2) в отличие от текстовых (JSON, XML), что повышает эффективность передачи в несколько раз
Хорошо описанный сервисный интерфейс, схема и типы
Работает со многими языками программирования (языко-независимый: Go, Java…)
Поддержка дуплексного стриминга (!) — это прямое попадание в яблочко для телеметрии
Много встроенных фич (аутентификация, шифрация, отказоустойчивость, компрессия, балансировка нагрузки и т. д.)
Поддержка Yang-моделей (модулей)
Нет смысла здесь останавливаться на подробном описании gRPC, потому что есть документация и, кроме того, хорошая книга — gRPC Up & Running Касуна Индрасири. Остановимся лишь на наиболее важных, с точки зрения использования gRPC, его характеристиках для конфигурации устройства и сетевой телеметрии, чтобы его преимущества в сравнении с другими вариантами RPC стали более понятными. Очень удобно, что в одном канале gRPC передаются стримы разных RPC. В свою очередь стрим — двунаправленный поток данных — может нести в себе разные сообщения.
Общение клиента с сервером происходит в диалоговом режиме запрос-ответ.
У разных сообщений могут быть разные категории, например:
Тип | Категория | Значения |
0 | Varint | int32, int64, uint32, uint64, sint32, sint64… |
1 | 64-bit | fixed64, sfixed64, double |
2 | Length-delimited | String, bytes, embedded messages… |
5 | 32-bit | fixed32, sfixed32, float |
Типы и категории gRPC-сообщений
В зависимости от этого при кодировании в protobuff у них может быть разная длина, далее при сериализации сообщения сначала записывается длина сообщения, для этого выделяются 4 байта, а уже потом само сообщение (length-prefix framing), передаваемое в бинарном формате.
И в заключение короткого обзора по gRPC хочется показать одну интересную фичу gRPC, которая может быть крайне полезна для сетевой телеметрии — это поддержка стриминга RPC. Он может быть клиентским, серверным или двусторонним.
gNMI и телеметрия плоскости передачи данных
gNMI-протокол. основанный на gRPC, придуман для модификации и получения конфигурации с сетевого элемента, а также для контроля и генерации сетевой телеметрии — сравниваем с Netconf, чтобы одним определением сервиса gRPC сразу закрыть две задачи: конфигурацию и телеметрию! gNMI также использует protobuff и предназначен для передачи любых древообразных типов данных (tree-structured data), а не только Yang.
Типы структурированных данных в gNMI:
Имя | Описание | Кодируемое значение |
JSON | Строка JSON, согласно RFC 715945 | 0 |
Bytes | Байты | 1 |
Proto | Сообщение, кодируемое в protobuff | 2 |
ASCII | ASCII строка, представляющая текст | 3 |
JSON_IETF | Строка JSON, согласно RFC 7951 | 4 |
Структурированные данные в gNMI
Вы могли обратить внимание, что имеется вроде бы два идентичных типа данных JSON, но это только на первый взгляд так. Ведь JSON_IETF ссылается на RFC 7951, а не на 7159, как JSON, — и это не опечатка. RFC 7951 вносит изменение в возможность кодирования Yang-моделей не только в XML — как это было задано в спецификации на Yang версии 1.1, в RFC 7950), но и JSON. И это отнюдь не схоластика, потому что тип кодирования JSON_IETF или JSON требуется выбирать при настройках коллекторов сетевой телеметрии gNMI, об этом поговорим ниже.
gNMI определяет 4 RPC:
Capabilities
Set
Get
Subscribe
Выше показаны примеры RPC, которые отвечают за конфигурацию и получение состояния устройства, когда в запросе передаётся путь и тип данных в случае Get либо значение в случае Set. Нам же более интересен вариант RPC для подписки на получение данных сетевой телеметрии, посмотрим на него.
Мы видим, что в запросе Subscribe Request содержится довольно много информации о том, что мы хотим получить в данных телеметрии:
Пути до источников данных (сенсоров), они разные у разных вендоров
Режим подписок на данные (про них в таблице ниже)
Общий префикс для всех указанных путей
QoS (возможность маркировки DSCP)
Возможность агрегации данных
Используемые модели (например, см. перечень моделей из каталога OpenConfig Yang-моделей ниже)
Возможность посылать только апдейты к первоначальным данным
Расширение (origin и специальные значения для него)
Итак, разобравшись с принципами работы gRPC и gNMI, необходимо ответить на вопрос, а какие данные по телеметрии плоскости передачи данных мы можем получить с их помощью от устройства? Как вы понимаете — это будет зависеть от используемых в rpc Subscribe Yang-моделей. Посмотрим для примера на варианты OpenConfig-моделей о состоянии интерфейсов и их счётчиках.
Заключение
На этом я заканчиваю описание базовых механизмов получения данных сетевой телеметрии на основе gRPC и gNMI.
На практике вы, вероятно, столкнётесь с необходимостью использовать сочетание телеметрии плоскости управления при помощи ВМР с одним или несколькими вариантами сбора телеметрии плоскости пересылки данных: gNMI + IPFIX/sFlow. Выбор вариантов Yang-моделей для сбора телеметрии будет определяться возможностями вашего оборудования (см. вопросы к вендору про Yang выше).
В следующей части поговорим о трендах развития сетевой телеметрии, а ещё расскажу, как мы работаем над внедрением сетевой телеметрии в облаке MWS.
