Pull to refresh

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

Reading time 5 min
Views 103K


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

Еще в начале 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
Tags:
Hubs:
+69
Comments 52
Comments Comments 52

Articles