На сайте ссылка сразу с первой страницы: Commertial support. Сейчас проект финансируется несколькими компаниями. Если удастся расширить финансирование, все будет вынесено в отдельную контору с несколькими full-time разработчиками
apache излишне тяжеловесен для такой конфигурации. Обычно ставят nginx или lighttpd.
Надо отметить, что NOC одновременно использует и PostgreSQL и MongoDB. Постгрес используется там, где выгоднее работать с реляционной моделью, а монго — в тех местах, где важна скорость или требуются документы со сложной структурой.
На отдельных задачах применение mongo дает ускорение в 4-5 раз. Новый Fault Management с ним заработал ощутимо быстрее.
Запланировано, хоть и не первым приоритетом. После того как задышит inventory, займемся workflow, а уже поверх него будем делать SD. Есть много задумок по общему дизайну и функционалу, будем привлекать новых разработчиков.
Мы не ставим задачи конкурировать с CA, HP и IBM, хотя часть функционала у нас перекрывается и что-то сделано лучше уже сейчас.
Далеко неполный список реально рабочих инсталляций: по ссылке. Среди них — социальная сеть на 100M+ пользователей, контакт-центр Сбербанка, один из самых динамично растущих операторов ШПД в России, несколько операторов ШПД среднего размера.
Над проектом работают профессионалы, которые хорошо понимают, что именно им нужно.
Проект открытый и активно развивается. Если есть энтузиазм и свежие идеи, предлагаю поучавствовать. Основное обсуждение ведется на IRC (#nocproject.org @ irc.freenode.net)
В таком случае, подозреваю, что ваши узкоспециальные задачи весьма широко распространены :)
Настоятельно рекомендую все-таки посмотреть на NOC, в частности на Map/Reduce Tasks (http://redmine.nocproject.org/boards/3/topics/1084?r=1094#message-1094).
Кстати, действительно, чем не угодил RANCID? Нужны веские основания для написания чего-то своего, если есть что-то такое же, только готовое. Все-таки готовый программный продукт, это не просто код, но и чужой опыт и чужая работа над ошибками. По закону подлости ошибки в своем скрипте проявятся как раз во время аварии :)
Я в свое время написал библиотечку для NOC'а. Она легковесная и умещается в одном файле: lib/nbsocket.py. Можете попробовать. Для наших задач вполне хватает.
Нет, SRX'ы мы загибали в Иннове :) С трехтысячниками были проблемы с софтом и с общей надежностью. Минимальной забивки трехтысячника хватит только на 0.7Mpps. Что-то еще удастся простейшими screen'ами вычистить.
Судя по вашей схеме, должна еще быть парочка MX'ов на девятке и десятке ;)
А какие преимущества даст куча SRX3600 перед парой SRX5800-х, которые набиваются SPC по мере потребности. Все платформа посерьезнее и понадежнее. Трехтысячники под нагрузкой у нас в свое время затыкались и переставали форвардить пакеты вообще.
С VIPRION'ами да, удобная штука и SOAP API хороший, можно простенькие вещи типа пулов и virtual'ов для юзеров организовывать.
SRX3600 не слабоват для этой задачи? Все-таки он сильно ограничен по pps, да и с софтом проблемы были.
А отдельные load balancer'ы у вас предусмотрены?
Надо отметить, что NOC одновременно использует и PostgreSQL и MongoDB. Постгрес используется там, где выгоднее работать с реляционной моделью, а монго — в тех местах, где важна скорость или требуются документы со сложной структурой.
На отдельных задачах применение mongo дает ускорение в 4-5 раз. Новый Fault Management с ним заработал ощутимо быстрее.
Мы не ставим задачи конкурировать с CA, HP и IBM, хотя часть функционала у нас перекрывается и что-то сделано лучше уже сейчас.
Над проектом работают профессионалы, которые хорошо понимают, что именно им нужно.
Настоятельно рекомендую все-таки посмотреть на NOC, в частности на Map/Reduce Tasks (http://redmine.nocproject.org/boards/3/topics/1084?r=1094#message-1094).
Судя по вашей схеме, должна еще быть парочка MX'ов на девятке и десятке ;)
С VIPRION'ами да, удобная штука и SOAP API хороший, можно простенькие вещи типа пулов и virtual'ов для юзеров организовывать.
А отдельные load balancer'ы у вас предусмотрены?