Comments 16
Хм :) А аффилирован ли как то Милош с сербским офисом?
для общения с устройствами можно использовать netconf/restconf. В интернете пишут, что и циски и хуавеи его поддерживают.
Все верно. Обычно, если устройство поддерживает NETCONF, то он покрывает часть функционала устройства, а CLI полностью. Поэтому основной упор делаем на CLI
Некоторые вендоры как раз через netconf сделаны. Ну и у цисок и у хуа одна и та же проблема - cli стабильней и полнее, чем остальные протоколы и более совместим между моделями вендора.
Проще говоря - с netconf/restconf ты всегда рискуешь наступить на проблемы для этих вендоров, с cli как правило нет.
Но принципиально никакой особой разницы нет, хоть через спецапишку вендора делается. А вот универсального решения для всех или хотя бы для какого-то заметного количества вендоров - нет. И cli тоже не серебряная пуля, к сожалению.
Даже в базовых моделях совместимость плохая? Базовая настройка интерфейсов должна быть одинаковая, нет?
Но принципиально никакой особой разницы нет, хоть через спецапишку вендора делается
парсить произвольный текст так себе удовольствие. Со структуированными данными всё-таки удобнее работать.
Даже в базовых моделях совместимость плохая? Базовая настройка интерфейсов должна быть одинаковая, нет?
Даже на одной модели на разных версиях софта.
парсить произвольный текст так себе удовольствие. Со структуированными данными всё-таки удобнее работать.
Да. Жизнь - боль :). Ну это просто специфика предметной области, не более того. Заставляет чуть больше думать головой.
Милош понимает, что он столкнётся с задачами масштабирования, так что смотрит в сторону библиотеки написанной на Golang
I/O bound задачи
Какая-то очень сомнительная аргументация. Особенно с учетом того, что различных инструментов для автоматизации сети/инфраструктуры на Python написано на порядок больше.
А, хотя это же Яндекс, совсем забыл...
Друг спрашивает, вы, случайно, не нанимаете?
Нанимаем. Друг может связаться со мной или нашей HR Катей через Telegram (@vadvolo, @djeibocat)
Cобирать подобную информацию лучше по snmp, а не через cli. Скорее всего подобную работу надо будет выполнять регулярно, а работа через cli сильно может забивать системы логирования и авторизации команд.
Бесспорно собирать данные через SNMP удобнее в том плане, что они будут в виде структуры, что избавит от парсинг, но это и добавляет сложности в проект. Тут в примере только одна секция конфигурации, но в реальной жизни настраивать нужно значительно больше и с большой долей вероятности даже у одного вендора не всё, что нужно будет доступно в SNMP, а еще нужно помножить эту проблему на количество вендоров. То есть в реальной жизни не получится сделать SNMP для получения данных, а CLI для конфигурации.
Кроме времени на разработку и поддержку дополнительной сущности в проекте потребуются ресурсы на поддержание доступа по SNMP. Поменяли адрес сервера - выкати настройки ACL или фаейрволла, пришло время поменять community string - не забудьте в проекте тоже поменять.
Я к чему всё это? То, что снаружи выглядит дешево и удобно, может обернуть болью в будущем. Да и это для примера только, в реальной жизни подобная система будет на порядок сложнее и обширнее по функционалу.
Хорошая статья, было бы интересно почитать,как происходит наполнение инвентаризационный системы, да и в целом, про автоматизацию всего жизненного цикла
У вас получается 526 человек технического персонала инфраструктурных подразделений для 20000 сетевых устройств? Жесть :)
Автоматизируем сеть Яндекса с Милошем: сервис конфигураций оборудования