[dvolodin]

Теоретически звучит красиво, обвязку в виде интерфейсов взаимодействия и ui вообще не проблема сделать(таких кодеров ВУЗы выпускают тысячами каждый год). Проблема во взаимодействии с железом и тут просто аццкая работа, по-человечески управлять железом это netconf, но с обвязкой в виде API он есть только у juniper(и то только олдскульный perl, с которого блевать тянет), по snmp управлять свои нюансы(не все хотят давать мибы или дают их под NDA, нет нормальной обработки исключительных ситуаций, шанс нарваться на cpu protection), telnet/ssh свои геморрои, web не везде есть или не полный, т.е. фактически бэкенд это должен быть набор жутких костылей, которые, кстати, не так уж и просто обобщить. Ну например, надо сконфигурировать dhcp-snooping, у кого-то trust порты прописываются на интерфейсе, у кого-то в влане, а ещё может быть вариант per-interface-per-vlan. Но самая фишка в том не как это обобщить(методы ООП весьма стандартны), а в том, что надо знать что обобщать, т.е. знать все возможные случаи(иначе потом придётся сильно переделывать родительские классы), т.е. быть специалистом(или иметь группу специалистов), который бы знал особенности настройки фич на различном железе. Поэтому сейчас фактически существуют либо vendor-specific системы, либо isp-specific; noc-project в этом плане уникален, посколько явно не является ни первым, ни вторым случаем, посмотрим как они будут дальше развиваться, особенно интересно в разрезе контрактных вендоров типа zte и huawei, которые очень закрыты для взаимодействия с внешним(по отношении к их прибыли) миром.

Это как раз то, что NOC делает хорошо. Причем поддерживается смешанный режим управления - через CLI и SNMP. Мы не заморачиваемся с ООП, а реализуем интерфейсы. Все что выше интерфейсов - абсолютно не зависит от вендора и железки. Та же таблица маков на выходе у всех получается абсолютно в одинаковом виде, даже при том, что MAC-адреса у разных вендоров пишутся по-разному. Для примера - в базовых механизмах topology discovery вообще нет ничего специфичного для вендора.

 

Вот в качестве примера - простенький скрипт, который дерет конфиги с DLink'ов: DLink.DxS.get_config.

[prog_nt]

Как программиста меня беспокоит производительность питона, особенно в такой сложной системе. Хотя сейчас я использую его в своем проекте в качестве клея, я уже недоволен его прожорливостью (может я просто не умею его готовить).

С производительностью у python получается относительно неплохо, большая часть нагрузки все равно уходит в базы или C-шные модули. Скажем, связка mongodb+python уделывает в целом аналогичные реализации на java+oracle :)

 

Та же генерация префикс-листов в NOC работает на порядок быстрее rtconfig, а десятки десятимегабайтных конфигов в параллель вытаскиваются существенно быстрее, чем с rancid.

Меня всегда умиляли такие аргументы на ровном месте, прям сказка какая то)

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

Я понимаю, что изначальная задача управлять сетью, а не гнаться за секундами, но если забить на эффективность, что будет при росте сети? Кроме того данных собирается и перемалывается огого, и время реакции такой системы меня тревожит. Кластеризация... Ресурсов много не бывает. А сети растут как на дрожжах.

Для примера, у меня в сети 2500 длинков, считать (snmp) и положить в базу все вланы 20 сек, fdb - 1,5 минуты , я боюсь предположить сколько это будет по телнету...

Одной из основных задач у нас - устранение человеческого фактора при конфигурировании девайсов, и при работе монтажников. А это значит постоянное реагирование на события, слежение за состоянием и настройками, и т.д. Понятно что все идет к исключению "голорукого" управления, и исключению ошибок на корню, но это лишь светлое будующее, кроме того монтажникам руки никто не выпрямит. Моя цель обеспечит качественную и бесперебойную работу транспортной сети минимальными усилиями (оптимизация обслуживания за счет автоматизации), сохранить клиентов. Если честно, я не могу себе представить где используется noc в текущем состоянии, но это очень предвзятое мнение, т.к. я его не видел в работе. Мой кругозор ограничен провайдером последней мили, и в данном ключе, увы, я скептически отношусь к этому проекту. Но я вижу, что он развивается, поживем увидим.

[s.lobanov]

prog_nt

Вам говорят про python vs ???, а вы про snmp vs cli, это два совершенно независимых фактора. В любом случае, в задачах management-а железа у вас большая часть времени будет уходить на взаимодействие с железкой, а не на динамическую компиляцию кода или контроль за выходы за пределы массива или gc.

В задачах массового мониторинга это имеет значение, но могу сказать, что при правильном приготовлении и python и java и прочее скриптово-байткодное работает очень быстро, просто некоторые олдскульные C/asm-программисты, ставшие почти ненужными никак не могу адаптироваться. Я пишу в основном на java и php(до python всё никак руки не доходят) и почти всегда упираюсь во внешние факторы(СУБД, тормознутость cpu сетевого оборудования и т.п.), а не в якобы "тормознутую" java. Назовёте быдлокодером? Да, пожалуйста, но свои задачи решаю и довольно оперативно именно благодаря тому, что думаю не о том где выделить память и где освободить, а о самой задаче.

 

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

[dvolodin]

Меня всегда умиляли такие аргументы на ровном месте, прям сказка какая то)

Две вполне конкретные и наиболее часто встречаемые задачи, куда уж конкретнее.

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

NOC'у в целом абсолютно все равно, как именно работает конкретный скрипт. Если есть необходимость, можно дергать и таблицы по SNMP, как это сделано для других профилей.

 

Я понимаю, что изначальная задача управлять сетью, а не гнаться за секундами, но если забить на эффективность, что будет при росте сети? Кроме того данных собирается и перемалывается огого, и время реакции такой системы меня тревожит. Кластеризация... Ресурсов много не бывает. А сети растут как на дрожжах.

Надо выбирать между секундами и общей пропускной способностью. Взаимодействие с железом у NOC - неблокирующее (включаяя SSH), и он легко может лопатить большое количество сессий одним процессом. Кластеризация на уровне работы с железом - автоматическая, активаторы объединяются в пулы с балансировкой нагрузки одной строчкой в конфиге. Если сетка большая - есть шардинг.

 

Для примера, у меня в сети 2500 длинков, считать (snmp) и положить в базу все вланы 20 сек, fdb - 1,5 минуты , я боюсь предположить сколько это будет по телнету...

Если производительность конкретного скрипта на конкретной железке не устраивает - всегда можно доработать скрипт. Скрипты нормально работают и с telnet/ssh и с snmp.

 

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

NOC это делает в автоматическом режиме. Есть валидация конфигов и управляемая реакция на внешние события. Есть генерация конфигов.

 

Понятно что все идет к исключению "голорукого" управления, и исключению ошибок на корню, но это лишь светлое будующее, кроме того монтажникам руки никто не выпрямит. Моя цель обеспечит качественную и бесперебойную работу транспортной сети минимальными усилиями (оптимизация обслуживания за счет автоматизации), сохранить клиентов.

Как первое связано со вторым?

Если честно, я не могу себе представить где используется noc в текущем состоянии, но это очень предвзятое мнение, т.к. я его не видел в работе. Мой кругозор ограничен провайдером последней мили, и в данном ключе, увы, я скептически отношусь к этому проекту. Но я вижу, что он развивается, поживем увидим.

Монтажник вообще не должен заниматься конфигурированием оборудования. В наряде указан номер порта, куда воткнуть абонента, этого ему достаточно.

 

Одна из основных целей проекта NOC - разработка универсальной и открытой платформы для автоматизации управления сетью. Использование общей платформы имеет ряд преимуществ:

 

* Не надо изобретать и заново реализовывать низкоуровневые механизмы и ядро системы

* Можно использовать чужие наработки по скриптам, обработке событий и интеграции

* Меньше рисков для бизнеса, так как нет жесткой привязки к конкретному программисту, занимающемуся автоматизацией

* Обмен опытом и идеями по автоматизации

Изменено 5 марта, 2012 пользователем dvolodin

[prog_nt]

Вам говорят про python vs ???, а вы про snmp vs cli, это два совершенно независимых фактора

Видимо я написал все слишком близко. Естесственно это 2 разных "наезда", в общем ключе - производительность.

В задачах массового мониторинга это имеет значение...

Предлагаю это больше не обсуждать, ибо оффтоп. К тому же КСВ хватает в сети, из которых все равно выходят каждый со своим мнением)

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

Я не говорю, что ВСЕ нужно делать именно так, просто в интересующем меня вопросе, ответ меня не устроил. В освоенной мною процедуре сбора, описанных Вами проблем я не имею.

Две вполне конкретные и наиболее часто встречаемые задачи, куда уж конкретнее.

Я понимаю, что задачи конкретные и часто встречаемые. Я имел ввиду, что Ваши утверждения голословны. Я не буду спорить, какие связки быстрее, какие медленнее, не сравнивал. Это просто выглядит как маркетинг, звучит круто, но не более того. Вопрос эффективности также предлагаю закрыть. Я этот вопрос затронул, я же и закрываю, ибо он не разрешим в рамках данного форума.

Монтажник вообще не должен заниматься конфигурированием оборудования. В наряде указан номер порта, куда воткнуть абонента, этого ему достаточно.

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

 

Извиняюсь, если я слишком грубо критикую, причем критикуя, не предлагаю ничего взамен.

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

 

Одна из основных целей проекта NOC - разработка универсальной и открытой платформы для автоматизации управления сетью. Использование общей платформы имеет ряд преимуществ:

На ум приходит некое деление городских провайдеров по принципу наличия КИС:

1. Совсем "бедные", которые пользуются существующими открытыми системами, и подстраиваются под них, либо делают все руками (парой скриптов), постоянно в поисках готовых решений.

2. Имеют в штате программистов и кучу наработок. Наработки корявые, постоянно требуют "ухода", но работают. Постоянно меняются под новые требования.

3. Имеют собственные отлаженные системы. В общем не нуждаются в помощи.

 

Для первого случая будем считать, что noc для них свет в конце тоннеля и т.д.

3й не интересует.

 

Как быть мне?)

* Не надо изобретать и заново реализовывать низкоуровневые механизмы и ядро системы

С одной стороны я считаю, что конкретный провайдер (2го типа) обычно использует определенный парк оборудования, большинство функций которого, уже обскриптованы. Кроме того все подсистемы жестко завязаны друг на друга.

Минусы: постоянная поддержка, постоянные доработки, соответственно затраты на программиста(ов) в штате. Но к системе постоянно меняются требования, добавляются новые фичи.

 

* Можно использовать чужие наработки по скриптам, обработке событий и интеграции

* Меньше рисков для бизнеса, так как нет жесткой привязки к конкретному программисту, занимающемуся автоматизацией

Зато есть привязка к проекту, разрабатываемому на заказ, хоть и открытому. Где гарантии, что проект не станет коммерческим, ведущие программисты останутся, а комьюнити сможет удержать проект в актуальном состоянии?

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

Если производительность конкретного скрипта на конкретной железке не устраивает - всегда можно доработать скрипт. Скрипты нормально работают и с telnet/ssh и с snmp.

Кто займется, например, вышеупомянутым скриптом сбора с длинков? Попросить комьюнити? А запрос нового функционала? Любезно реализуют? Либо подстраиваться под то что есть. Либо опять же отдельно нанимать для этого новых, либо переквалифицировать существующих программеров, либо повезет с питонистом (по моему мнению преобладает в данном случае php/perl). В любом случае это вложение денег в noc. Это может и не плохо, но риски?

 

В общем получается, что вопрос такого плана: целесообразность перевода существуюшей частной системы управления сетью не законченной, не отлаженной, развивающейся параллельно на noc. Наверное у меня одного такой вопрос)

[Dmitry1]

Кто займется, например, вышеупомянутым скриптом сбора с длинков? Попросить комьюнити? А запрос нового функционала? Любезно реализуют? Либо подстраиваться под то что есть. Либо опять же отдельно нанимать для этого новых, либо переквалифицировать существующих программеров, либо повезет с питонистом (по моему мнению преобладает в данном случае php/perl). В любом случае это вложение денег в noc. Это может и не плохо, но риски?

 

В общем получается, что вопрос такого плана: целесообразность перевода существуюшей частной системы управления сетью не законченной, не отлаженной, развивающейся параллельно на noc. Наверное у меня одного такой вопрос)

Как ни странно, но именно универсальными скриптами для D-Link и может похвастаться NOC. Охвачен практически весь модельный ряд коммутаторов. Включая совсем уж экзотические.

Если есть какие-то вопросы по состыковке NOC и D-Link - добро пожаловать на канал #nocproject.org на irc.freenode.net

[dvolodin]

[В общем получается, что вопрос такого плана: целесообразность перевода существуюшей частной системы управления сетью не законченной, не отлаженной, развивающейся параллельно на noc. Наверное у меня одного такой вопрос)

Если такой вопрос поднимается, то, как минимум, есть предпосылки и мотивация для поиска альтернатив или дополнений к имеющемуся решению.

Универсального ответа Вам никто не даст, надо смотреть на требования, на то, что есть сейчас, оценивать сроки, стоимость доработки, внедрения и риски для имеющегося решения и для альтернатив.

 

В рамках open-source проекта работает мультипликативный эффект - даже небольшое вовлечение каждого из членов community ускоряет развитие проекта, в то время как небольшая команда из нескольких разработчиков, трудящихся над одним закрытым нетиражируемым решением в состоянии обеспечить только линейное развитие.

[dvolodin]

Приступили к доработке VC Management:

* Практически полностью переписан UI

* Новый UI изначально рассчитан на работу с большим количеством VLAN'ов

* Появился открытый REST/JSON интерфейс для манипулирования VLAN'ами. Теперь сторонние системы могут создавать VLAN'ы в NOC и разносить порты по VLAN'ам, что полезно для интеграции с биллингом и сторонними панелями управления

* По базе интерфейсов автоматически определяется, какие сети в каких VLAN'ах светятся.

 

Прогресс - по ссылке

[dvolodin]

Приступили к тестированию официального VM image. Подробности по ссылке.

 

Image полностью готов к работе, теперь приступить к тестированию и использованию NOC можно через пару минут после скачивания,

[SergeiK]

Это правильный путь. Как выйдет - проверим.

[eill]

dvolodin, качаю, для тестов и "напосмотреть" самое то, спасибо :)

[catalist]

А как вы принимаете запросы на новый функционал?

[dvolodin]

А как вы принимаете запросы на новый функционал?

Да, принимаем. Можно в личку.

[`kk]

А как вы принимаете запросы на новый функционал?

 

можно через http://bt.nocproject.org/secure/IssueNavigator.jspa

[t0ly]

хотелось бы описания того что реально работает и что не работает.

а то поставил VM.Image, экспортнул оборудование, а понять из документации что делать со всем проме конфигов сложно.

в irc ребята помогают по техоньку, огромное им за это спасибо, но овбщем и целом на внедрение чего тратить время, и на внедрение чего не тратить пока не очень понятно.

 

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

 

а вообще продукт нравится.

Изменено 13 апреля, 2012 пользователем t0ly

[dvolodin]

После 4 месяцев разработки и 130 закрытых заявок вышел NOC 0.7(3).

 

Основные изменения:

 

* IPAM auto-discovery

* Доработана поддержка IPv6 в скриптах

* VC Management полностью переписан на ExtJS

* VRFs/Prefixes/Addresses получили настраиваемые состояния

* Доработана поддержка Cisco IOS XR and Extreme

* Новые интерфейсы и скрипты: IGetDOMStatus, IGetMPLSVPN

* REST и JS интерфейс для запуска Map/Reduce tasks

* В сниппеты можно вставлять python-код

* Экспериментальная подсистема GIS

 

С новым релизом также вышел первый официальный VM image.

Подробности по ссылке

[Ksandermeister]

Всем привет.

Хочу использовать NOC для управления адресным пространством и его распределением, есть ли там такая возможность? Например я добавляю сетку /16 как свободную. Дальше мне эту сеть нужно постепенно разбивать по /24 и меньше. Мне надо что бы программа автоматически разбивала сетку, выдавая свободные адреса.

[Dmitry1]

Всем привет.

Хочу использовать NOC для управления адресным пространством и его распределением, есть ли там такая возможность? Например я добавляю сетку /16 как свободную. Дальше мне эту сеть нужно постепенно разбивать по /24 и меньше. Мне надо что бы программа автоматически разбивала сетку, выдавая свободные адреса.

NOC это умеет. Плюс с привязкой к железкам, AS и т.п.

[Ksandermeister]

Умеет, это здорово! Но как там это все настраивать, куда добавлять сети, как их разбивать, ни одного толкового мануала я не нашел, самому пока тоже не понятно как там это все реализовывается.

[Dmitry1]

Умеет, это здорово! Но как там это все настраивать, куда добавлять сети, как их разбивать, ни одного толкового мануала я не нашел, самому пока тоже не понятно как там это все реализовывается.

Зайди на канал #nocproject.org на irc.freenode.net.

 

P.S.

Кстати, там есть возможность автоматом добавлять сети и IP, выдирая их с железяк.

[dvolodin]

Всем привет.

Хочу использовать NOC для управления адресным пространством и его распределением, есть ли там такая возможность? Например я добавляю сетку /16 как свободную. Дальше мне эту сеть нужно постепенно разбивать по /24 и меньше. Мне надо что бы программа автоматически разбивала сетку, выдавая свободные адреса.

Такой функционал есть. Кроме того, NOC умеет заполнять базу IPAM автоматом прямо с железа.

 

Умеет, это здорово! Но как там это все настраивать, куда добавлять сети, как их разбивать, ни одного толкового мануала я не нашел, самому пока тоже не понятно как там это все реализовывается.

Чего там может быть непонятного? Смотри раздел Screencasts

[dvolodin]

В грядущей версии 0.7(4) появилась новая полезная вещь - Custom Fields.

Краткий обзор - по ссылке

[dvolodin]

Вышел NOC 0.7(4).

 

В новой версии появилась возможность добавлять собственные поля в объекты, оптимизирована система Service Activation, исправлены ошибки в UI.

 

Подробности по ссылке

[postuser]

Можно ли связать IPAM с VLAN, т.е. при создании ip адреса или сети указать vlan, в котором она работает. Только начинаю пользоваться NOC, но кажется, что неудобно хранить отдельно vlan-ы и ip.

Также интересует, как правильно связывать NOC с биллингом (в плане ip адресов клиентов). Т.е. например одну из систем (биллинг или NOC) сделать основной, а другую автоматически синхронизировать.

[zi_rus]

для адреса нельзя, для префикса можно, просто берешь и указываешь там есть специальное поле - это в ipam. если железки в системе завести, он сам найдет соответствие, но только для vlan -> ip в таблице вланов, в таблицу ip этого не отражает.

 

а с помощью этого

http://kb.nocproject.org/display/BLOGS/IPAM+REST

можно любую сторону сделать основной