0,0
рейтинг
27 июля 2011 в 17:46

Администрирование → NOC: Комплексный подход к управлению сетью



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

Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих.

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


В целом нужно отметить, что NOC — это не система мониторинга, и не альтернатива zabbix/nagios/кактус/etc.
Основная задача — автоматизация повседневной работы центра управления сетью.

При разработке системы мы исходили из нескольких предпосылок:

Одна из предпосылок — источник информации должен быть один и им должно быть удобно пользоваться.

Вторая предпосылка — делегирование полномочий. Данные в системе набиваются разными людьми из разных подразделений.

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

Четвертая — гремлинов среди гоблинов всегда хватает. Существенная часть аварий вызвана человеческим фактором. Нужно иметь возможность быстро понять, что же такого наворотили и что привело к аварии. Для этого надо сопоставлять и изменения конфигурации, и события syslog/snmp и многое другое.

На настоящий момент NOC состоит из нескольких модулей:


Address Space Management (IPAM) — управление адресным пространством. Основное отличие от других решений — поддержка независимых адресных пространств в отдельных VRF, иерархичность выделения блоков адресов, делегирование полномочий. Наример, можно выделить блок на город и дать права на управление блоком городскому филиалу, а дальше пусть они сами воротят что хотят в отведенных пределах. При этом по отчетам можно отслеживать, насколько деятельность отдельного города соответсвует общим политикам. Подсистема нормально работает при десятках тысяч выделенных блоков и сотнях тысяч адресов и поддерживает адреса IPv4 и IPv6


DNS Management — если уж привели в порядок адреса, то почему бы не синхронизировать все с DNS. Таким образом получается единый интерфейс для управления зонами и provisioning зон на различные DNS серверы по описанной логике. Например, данные для зон можно генерировать автоматом, зоны города и клиентов этого города уедут на серверы, расположенные в этом городе. Отпадает необходимость в slave зонах, можно легко мигрировать на другие DNS-серверы. Попутно по базам регистраторов отслеживается, когда протухнет конкретный домен.



Service Activation — интерфейс для работы с оборудованием. Поддерживается широкий спектр оборудования. Основная идея заключается в том, что существует набор скриптов-кубиков, имеющих общий интерфейс, выполняющих какое-нибудь действие и целиком и полностью абстрагирующих особенности работы конкретной железки. Примеры — получить конфиг, получить версию софта, создать vlan, и так далее. Полученные кубики можно заставить работать в разных комбинациях и решать при помощи них весьма широкий спектр задач. Также реализован механизм map/reduce tasks, который позволяет выполнить однотипное действие на большом количестве оборудования и проанализировать результат исполнения.


Configuration Management — отслеживает, где, что и когда изменилось. Начиналось как интерфейс к mercurial, сейчас функционал модуля стал гораздо больше. В частности, при изменении конфига свича в городе специально выделенному инженеру в этом городе придет сообщение. В большом количестве случаев он успеет оперативно отреагировать на местную самодеятельность, даст по шапке и предотвратит аварию. Система умеет проверять полученные конфиги на предмет соответсвия установленным политикам и способна принимать активные действия в случае подозрительных ситуаций.


VC Management — управление VLAN'ами. При полном развертывании достаточно заносить и удалять vlan'ы в базу, и они автоматически будут появляться на нужных свичах, вне зависимости от вендора. Например, в одной инсталляции надо было рулить одновременно горой кисковских шеститонников, четырехтоников, nexus'ов, 3750/CBS3120, force10 E, C, S-series, HP ProCurve и GbE2c и мелкими Alcatel'ами.

Fault Management — сбор, анализ и кореллирование событий syslog/snmp trap с железа. NOC применяет оригинальный и гибкий подход к обработке событий. FM — отдельная тема для разговора, можно сказать, что вменяемых open-source реализаций просто нет, а вменяемые коммерческие можно пересчитать по пальцам одной руки. Текущая реализация FM в NOC способна обрабатывать сотни событий в секунду и выявлять среди них аномальные и аварийные ситуации. Коррелятор находит связи между авариями и пытается установить первопричину. Например, упавший линк способен породить сотни аварий разных типов в разных местах сети. Коррелятор, оперируя знаниями о топологии сети и встроенным набором правил в может установить, что истиная причина множества аварий кроется именно в упавшем линке и явно укажет, где надо искать причину

Peering Management — все, что связано с пирингом и BGP. Позволяет хранить базу пиров, генерировать фильтры для BGP, обновлять базу RIPE и делать многое другое. Когда счет пирам идет на десятки и сотни, вещь незаменимая.

Knowledge Base — обычная встроенная wiki с набором дополнительных интересных макросов. Например, при помощи макроса rack можно прорисовать набивку ряда из стоек. В KB можно хранить инструкции, сертификаты, договоры, правила и политики, полезные рецепты и так далее.

Performance Management — активный сбор параметров производительности (в том числе и snmp). Модуль достаточно интересный и еще будет активно дорабатываться.

Inventory — общая база по физическому железу. Позволяет работать с объектами разных уровней — от города и узла связи до стойки и шнурка питания коммутатора. Модуль находится в активной разработке.

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

NOC является open-source, распространяется по лицензии BSD и успешно эксплуатируется уже несколько лет в ряде крупных российских и зарубежных сетей. Основной язык программирования — python. В качестве баз данных используется связка PostgreSQL и MongoDB. Web-интерфейс реализован на Django. Приглашаем компететнных специалистов принять участие в работе над проектом, у нас есть множество интереснейших направлений работы для светлых голов.

Сайт проекта: http://redmine.nocproject.org.
IRC: #nocproject.org на irc.freenode.net
Дмитрий Володин @DmitryVolodin
карма
37,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (52)

  • +9
    Дима очень скромный :))

    Его nocproject используется в пачке мест уже, включая проекты с более чем 100 миллионами пользователей

    Реально — лучше вместо написательства отдельных велосипедов подключаться к этому замечательному опенсорс проекту.
  • +3
    Далеко неполный список реально рабочих инсталляций: по ссылке. Среди них — социальная сеть на 100M+ пользователей, контакт-центр Сбербанка, один из самых динамично растущих операторов ШПД в России, несколько операторов ШПД среднего размера.

    Над проектом работают профессионалы, которые хорошо понимают, что именно им нужно.
    • +1
      Штука фантастическая, сапсибо за нее! Я задумал писать подобный проект (но значительно проще функционалом, конечно — мне далеко до уровня разработчиков вашего продукта). К нему бы еще документацию — было бы вообще замечательно
    • +2
      Я осмелюсь предположить, что если вы вынесете названия Badoo и Innova куда-нибудь в начало статьи, то её прочитает куда больше людей. Слишком уж здесь много кустарных поделок и просто новых проектов презентуется, так люди сразу серьёзнее отнесутся.
      • +2
        Не контора красит продукт, а люди контору.
  • +1
    А я на днях думал, надо поискать что-то уневерсальное, а оно вот! есть! Буду пробовать.
    • +1
      И написан в моей любимой связки :) python/django/mongo-db
  • +2
    500 — Internal Server Error — хабраэффект?
  • +1
    Ага, от сайта только иконка прогрузилась. :)
  • +1
    инетересная штука, пощупаю во время отпуска
  • +1
    Я почитал установку, ставится он через fastcgi, как насчет mod_wsgi? пробовали?
    • +1
      Нет, не пробовали. В основном ставится как FastCGI. Количество HTTP запросов относительно невелико и принципиальной разницы не будет.
      • +1
        просто у меня уже связка настроенна. Ладно попробую отпишу потом.
        • +1
          Да, будет интересно посмотреть на результат. Отпишите по итогам тестирования, обновим документацию
          • +1
            только оперативно не обещаю, щас завал на работе (включая коммутацию, старое наследие админов)
            Как только так сразу.

            Примерно планируется такая схема
            centos6 — apache/modwsgi/mongo_db
            а там будет видно.
            • +2
              apache излишне тяжеловесен для такой конфигурации. Обычно ставят nginx или lighttpd.

              Надо отметить, что NOC одновременно использует и PostgreSQL и MongoDB. Постгрес используется там, где выгоднее работать с реляционной моделью, а монго — в тех местах, где важна скорость или требуются документы со сложной структурой.

              На отдельных задачах применение mongo дает ускорение в 4-5 раз. Новый Fault Management с ним заработал ощутимо быстрее.
              • +1
                Да я не как не могу себя заставить сесть и освоить light или nginx.(хотя конечно надо бы)
                про psql и mongo понял.

                В общем надо будет все развернуть да тестировать.
  • +2
    По описанию — просто отлично, Вам бы еще добавить возможность ServiceDesk с полноценным Incident, Problem и Change Managementом. Но это такое — не совсем обязательно, просто будет очень конкурентное решение на поле таких бойцов как IBM и HP.
    • +1
      Запланировано, хоть и не первым приоритетом. После того как задышит inventory, займемся workflow, а уже поверх него будем делать SD. Есть много задумок по общему дизайну и функционалу, будем привлекать новых разработчиков.

      Мы не ставим задачи конкурировать с CA, HP и IBM, хотя часть функционала у нас перекрывается и что-то сделано лучше уже сейчас.
      • +1
        Кстати, очень бы хотелось увидеть возможность купить продукт(support). (пусть не сейчас, в будующим)
        Есть органищации, где не очень любят opensource (точнее не любят когда нельзя заплатить :) )
        • +3
          На сайте ссылка сразу с первой страницы: Commertial support. Сейчас проект финансируется несколькими компаниями. Если удастся расширить финансирование, все будет вынесено в отдельную контору с несколькими full-time разработчиками
          • +1
            Честно не увидел. Завтра украду время на работе и сяду за изучение.
  • +2
    Я когда-то работал в конторе, которая делала NOC уровня как на фотке в начале статьи.

    Так вот самое востребованное клиентами — это карта сети, масштабируемая по уровням 2-3, лучше больше, отображающая состояние и проблемы. Потому что визуальный контроль больше 10-20 элементов в таблице уже труден, а когда их сотни — невозможен.

    Второе по востребованности — это управление сервисами. То есть хорошо управлять vlan-ами и BGP абстрагируясь от вендоров железа, но проложить маршрут от точки до точки, включая и radius и учитывая CLA и QoS — это дорого стоит.

    Ну и для fault management неплохо бы иметь управление и контроль redundancy, потому что проектные возможности учитывают однократный сбой, редко 2 или более, а такое бывает и если случается — контроль, а главное понимание теряется полностью.
    • +1
      VLAN'ы от точки к точке в L2 топологии NOC умеет прокидывать и сейчас (сторонним модулем). MPLS топологии пока не понимает, но работы ведутся. Как доделаем каталог сервисов, можно будет сделать проброс VLANов в произвольных комбинациях уже без костылей, а заодно к rule-based механизму корреляции аварий добавим graph-based по зависимостям сервисов.

      Визуализация схем сети с наложенными дополнительными данными — отдельная тема, скоро и до нее дойдут руки.
  • +1
    Для ленивых коллеги подготовили Virtual Appliance с NOC 0.6.4 для SuSE. Для предварительного знакомства достаточно.
  • +2
    Большое спасибо за статью, приятно знать, что есть люди, которые занимаются такими Open Source разработками.
  • +3
    Толковым студентам, ищущим тему для дипломной работы, можем подкинуть несколько интересных тем и, возможно, посодействовать с преддипломной практикой. Если кому интересно, пишите мне.
    • +1
      Это не говоря потом что таких толковых студентов ждет большое и светлое будущее, которому можно поспособствовать :)
      • +1
        Зависит от степени толковости. Хорошему молодому специалисту всегда можно создать условия для карьерного роста :)
  • 0
    Обидно что проект разрабатывается русскоговорящими, но в сторону локализации на русский язык даже не смотрят.
    • +1
      Почему не смотрят? Базовая i18n есть, пусть и не по всем модулям. Fault Management вообще нативно умеет выводит сообщения на том языке, который выбрал оператор.
    • 0
      А зачем?
      Ну то есть я имею в виду, что ведь это продукт не для Васи-заборостроителя, а для Васи-админа. То есть человек должен уже владеть базовым английским языком.
      • +1
        Сменным операторам удобнее читать на родном языке. Другое дело, что устоявшиеся технические требования лучше не переводить и тектст превращается в страшную русско-английскую мешанину
  • 0
    ого =) плюсануть не могу, но плюсанул бы)) заинтересовал DNS Management и Configuration Management. посмотрим с чем это едят.
  • +1
    Вроде круто.
    Предлагаю вам в следующей статье набросать мануал с картинками, а то пока толком не понятно, как это всё работает в сети с разношёрстным оборудованием
    • 0
      Мануал потянет на пару тысяч листов :)

      Может быть сделаю еще несколько статей по отдельным применениям
      • +1
        Надо я думаю вводуню етму сделать, что делать после установки :)
        • 0
          Да, я поставил и ооочень долго теперь вникаю =)
          • 0
            Как и я.
            • 0
              Ребят, заходите на IRC: #nocproject.org на irc.freenode.net
              там поможем разобраться =)
  • 0
    Среди всего этого у меня есть одна претензия «управлять безопасностью» — это слова ни о чём.
  • 0
    Описание заинтриговало, попробую развернуть…
    • 0
      При попытке доступа к /inv/vendor/add/ вываливается 404, обработчик не находит
    • 0
      TemplateSyntaxError at /sa/managedobject/
      • 0
        Caught DoesNotExist while rendering: AlarmClass matching query does not exist.
        {% result_list cl %}
      • +1
        Коллеги, давайте все ошибки тикетами на сайте
        • 0
          Хорошо =)
  • 0
    оффтопик:
    а кто-нибудь видел подобные системы для учета/управления в пределах дц — стойки, питание, склады итд?

    я видел
    racktables.org/
    rackman.jasonantman.com/
    flux.org.uk/projects/rackmonkey/
    sourceforge.net/apps/trac/nventory/wiki
    racksmith.net/
    rackview.sourceforge.net/

    но все это уныло чуть менее чем полностью.
    • 0
      В нашем inventory все это планируется
    • 0
      Использую racktables для учёта. Не холивара ради, а из чистого любопытства: какого функционала не хватает?
  • 0
    Продолжаете сейчас работу над проектом?
  • 0
    Некропост: картинок ни у кого не завалялось?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.