prog_nt

Видимо я написал все слишком близко. Естесственно это 2 разных "наезда", в общем ключе - производительность. Предлагаю это больше не обсуждать, ибо оффтоп. К тому же КСВ хватает в сети, из которых все равно выходят каждый со своим мнением) Я не говорю, что ВСЕ нужно делать именно так, просто в интересующем меня вопросе, ответ меня не устроил. В освоенной мною процедуре сбора, описанных Вами проблем я не имею. Я понимаю, что задачи конкретные и часто встречаемые. Я имел ввиду, что Ваши утверждения голословны. Я не буду спорить, какие связки быстрее, какие медленнее, не сравнивал. Это просто выглядит как маркетинг, звучит круто, но не более того. Вопрос эффективности также предлагаю закрыть. Я этот вопрос затронул, я же и закрываю, ибо он не разрешим в рамках данного форума. Монтажник не занимается конфигурированием девайсов, монтажник меняет топологию сети, переключает клиентов. Причем в двух разных компаниях была разная политика работ, и разная компетенция монтажников, ни один из подходов не спасал от ошибок. Монтажник за ошибку заплатит штраф 500 рублей, а в итоге уйдут клиенты, и компания потеряет больше. У админов тоже имеются ошибки. Извиняюсь, если я слишком грубо критикую, причем критикуя, не предлагаю ничего взамен. Сейчас я пытаюсь найти ответ прежде всего для себя. Принимая такую позицию: отказа от внедрения noc у себя на сети, я боюсь оказаться не правым. Поэтому мне нужно сделать вывод, либо да, все таки noc хорошая штука для нас и внедрение имеет определенный профит, либо нет. На ум приходит некое деление городских провайдеров по принципу наличия КИС: 1. Совсем "бедные", которые пользуются существующими открытыми системами, и подстраиваются под них, либо делают все руками (парой скриптов), постоянно в поисках готовых решений. 2. Имеют в штате программистов и кучу наработок. Наработки корявые, постоянно требуют "ухода", но работают. Постоянно меняются под новые требования. 3. Имеют собственные отлаженные системы. В общем не нуждаются в помощи. Для первого случая будем считать, что noc для них свет в конце тоннеля и т.д. 3й не интересует. Как быть мне?) С одной стороны я считаю, что конкретный провайдер (2го типа) обычно использует определенный парк оборудования, большинство функций которого, уже обскриптованы. Кроме того все подсистемы жестко завязаны друг на друга. Минусы: постоянная поддержка, постоянные доработки, соответственно затраты на программиста(ов) в штате. Но к системе постоянно меняются требования, добавляются новые фичи. Зато есть привязка к проекту, разрабатываемому на заказ, хоть и открытому. Где гарантии, что проект не станет коммерческим, ведущие программисты останутся, а комьюнити сможет удержать проект в актуальном состоянии? Причем проект довольно сложный, за счет модульности, универсальности и т.д. Кто займется, например, вышеупомянутым скриптом сбора с длинков? Попросить комьюнити? А запрос нового функционала? Любезно реализуют? Либо подстраиваться под то что есть. Либо опять же отдельно нанимать для этого новых, либо переквалифицировать существующих программеров, либо повезет с питонистом (по моему мнению преобладает в данном случае php/perl). В любом случае это вложение денег в noc. Это может и не плохо, но риски? В общем получается, что вопрос такого плана: целесообразность перевода существуюшей частной системы управления сетью не законченной, не отлаженной, развивающейся параллельно на noc. Наверное у меня одного такой вопрос)

С производительностью у python получается относительно неплохо, большая часть нагрузки все равно уходит в базы или C-шные модули. Скажем, связка mongodb+python уделывает в целом аналогичные реализации на java+oracle :) Та же генерация префикс-листов в NOC работает на порядок быстрее rtconfig, а десятки десятимегабайтных конфигов в параллель вытаскиваются существенно быстрее, чем с rancid. Меня всегда умиляли такие аргументы на ровном месте, прям сказка какая то) Обобщение интерфейсов - это да, одно из самых важных, тут бы не промахнуться, но вот реализация меня неприятно удивила, например, управления вланами на длинках, по телнету мне даже в голову не приходило это делать, fdb - OMG, о какой эффективности идет речь... с чем сравнивается производительность... Я понимаю, что изначальная задача управлять сетью, а не гнаться за секундами, но если забить на эффективность, что будет при росте сети? Кроме того данных собирается и перемалывается огого, и время реакции такой системы меня тревожит. Кластеризация... Ресурсов много не бывает. А сети растут как на дрожжах. Для примера, у меня в сети 2500 длинков, считать (snmp) и положить в базу все вланы 20 сек, fdb - 1,5 минуты , я боюсь предположить сколько это будет по телнету... Одной из основных задач у нас - устранение человеческого фактора при конфигурировании девайсов, и при работе монтажников. А это значит постоянное реагирование на события, слежение за состоянием и настройками, и т.д. Понятно что все идет к исключению "голорукого" управления, и исключению ошибок на корню, но это лишь светлое будующее, кроме того монтажникам руки никто не выпрямит. Моя цель обеспечит качественную и бесперебойную работу транспортной сети минимальными усилиями (оптимизация обслуживания за счет автоматизации), сохранить клиентов. Если честно, я не могу себе представить где используется noc в текущем состоянии, но это очень предвзятое мнение, т.к. я его не видел в работе. Мой кругозор ограничен провайдером последней мили, и в данном ключе, увы, я скептически отношусь к этому проекту. Но я вижу, что он развивается, поживем увидим.

Скорее хвастаюсь), потому что рекламировать нечего. Желание развивать идею какими-то общими усилиями имеется, но этим вопросом пока некогда заниматься... Это да, кроме железа у каждого свой подход к построению сетей в принципе. Но я вообще для себя выделяю среди подсистем провайдера (биллинг, CRM) именно задачу управления транспортной сетью, и считаю, что возможно создать универсальный "фреймворк", некий бэк-енд с обширными возможностями, + полнофункциональный GUI, а также API для взаимодействия с другими системами (например доступ пользователей к сети + биллинг), включая АПИ для интеграции UI в существующие системы (по крайней мере такая архитектура у меня в плане). Время покажет)

http://forum.nag.ru/forum/index.php?showtopic=47185&view=findpost&p=694328

Я уже несколько лет работаю у интернет провайдера, сначала админом, потом перерос в программера. Основное занятие создание системы управления сетью. Т.к. ни комерческие ни открытые продукты не обеспечивают должного уровня удобства и функционала, приходится думать что-то свое. В связи с тем, что недавно нас купили/объединили, имеем в дополнение подобную систему на базе заббикса. Т.к. все это писалось разными людьми, в итоге имеем базу оборудования, синхронизацию в заббикс, кучу доп скриптов на php/perl/python и 2 GUI - десктоп и веб (как это все печально). 1. пункт самый трепетный для меня, как админа, с него я и начинал. По сей день он является основным при анализе и локализации проблем. 2. заббикс с одной стороны, с другой - имеются самописные обработчики/сигнализаторы. 3. заббикс 4. заббикс (хотя это немного другая задача, чем управление сетью) 5. Интерфейс управления девайсами хотелось иметь единообразный, а в телнет/ссш/веб лазить только по необходимости, при отсутствии реализованных функций. В этом ключе и двигаемся. 6. svn 7. xls файлик) 8. Имеется, на базе карты сети, но будет дорабатываться до максимального автомата. Кроме этих фич(хотелок) есть еще куча других (некоторые возможно есть в noc). Например: * построение топологии с нуля (хотя есть проверка топологии на основе имеющейся инфраструктуры). * поддержание настроек девайсов в нужном состоянии при изменении топологии, например раздача iptv, различные типы клиентов, разные настройки (частично реализовано) и т.д. * визуализация L3, в частности включив ospf на сети, начали иметь проблемы маршрутизации. и многие другие Хотя наверное необходимый фукнционал зависит от используемого оборудовани и проблем с ним. У нас 90% сети на длинках. Как разработчику, мне конечно хочется спроса на продукт, но в данный момент система развивается для удовлетворения нужд конкретного провайдера уровня города (MAN/inet). И я думаю так делают многие провайдеры. Noc смотрел в качестве готового велосипеда, но скудность документации сделала свое дело, абсолютно не понятно было (на тот момент) как это все готовить, и что "оно" умеет. Также сказалось отсутствие нужного количества свободного времени для исследования, т.к. текущие проблемы нужно решать. Offtopic Как программиста меня беспокоит производительность питона, особенно в такой сложной системе. Хотя сейчас я использую его в своем проекте в качестве клея, я уже недоволен его прожорливостью (может я просто не умею его готовить). Это не в коем случае не является рекламой продукта, и не конкуренция noc, просто делюсь с тем как мы решаем задачу (и немного хвастаюсь :-). Однако судя по постам, noc не является панацеей для всех типов провайдеров. Кроме того я понял, что noc делается на заказ, хотя есть и комьюнити, которое помогает в развитии в ширину. пара скринов (карта полностью интерактивна): Состояние STP дерева Бардак с 1 вланом Главное окно девайсов