Как стать автором
Обновить

NOC: Введение в Fault Management

Сетевые технологии


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

Существует немало систем мониторинга, которые выполняют активную проверку сети и сетевых сервисов по протоколам ICMP и SNMP. Быстрый и неправильный ответ – очевиден. Достаточно настроить волшебную систему мониторинга, и наступит полное счастье. Вся обманчивость этого заблуждения понимается со временем. Сначала выясняется, что обнаружение аварий происходит только на тех сервисах, которые поставлены на мониторинг. Хорошо, если удалось накрыть хотя бы основные сервисы. Остальные, увы, будут ставиться на мониторинг в результате горького опыта и ценой запоздалой реакции. Чуть попозже начинается мистика. Что-то явно работает не так, есть жалобы, но система мониторинга говорит, что все в порядке. В чем причина?

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

Примерно посередине приходит понимание, что в случае серьезных аварий от активной системы мониторинга вреда становится больше, чем пользы, так как она выдает слишком много информации и мешает обнаружить реальную проблему. Конечно, активные системы мониторинга, полезны и выполняют свою функцию. Но очевидно, что они не являются серебряной пулей и полагаться всецело на них недальновидно. На помощь приходят системы Fault Management (FMS). В первом приближении – это системы анализа и обработки событий. В общем потоке наверняка есть несколько событий с информацией об аварии. Первая задача FMS – отфильтровать лишнее и оставить только то, что требует непосредственного внимания. Обычно все равно остается слишком много информации и операторы не успевают ее обрабатывать. Поэтому, система FMS должна приоритезировать обнаруженные аварии, чтобы позволить выделить наиболее существенные. Далее выясняется, что события не являются независимыми, а некторые из них связаны между собой. В результате корреляции событий FMS устанавливает связь между авариями и скрывает избыточную информацию. Дальше возникает самый сложный вопрос: обнаружено множество аварий различной степени тяжести, какая из них является причиной? Например, упавший линк может порвать сотню MPLS LSP, десятки BGP-сессий, вызвать перестройку топологии в IGP и сделать на время недоступной ферму из тысячи серверов. Некоторые системы FMS осуществляют поиск причины (root-cause analysis). В результате оператору будет показана истинная причина всех наведенных аварий и можно будет не тратя времени немедленно приступить к устранению неисправностей.

Определимся с терминологией:
  • Событие (Event): сообщение о происшедшем и наступившем в произвольной точке сети в произвольное время и вызвавшее изменение состояния сети
  • Авария (Alarm): Значительное происшествие, которое ведет к частичной или полной деградации сервиса и требует непосредственной реакции оператора


Основные достоинства FMS — по сравнению с активными системами мониторинга. До поры до времени они пассивны, не создают излишнюю нагрузку на сетевые устройства, просто слушают логи и SNMP Trap'ы, которые железки и так выдают. Кроме того, они обладают еще одним замечательным качеством — аварийные ситуации начинают отслеживаться сразу после того, как пойдет поток событий, при этом нет необходимости указывать системе, на что именно ей надо смотреть. Результат на первых порах просто шокирует: система находит давно умершие блоки питания, сбойные трансиверы, тыкает в мигающие линки и всячески мотивирует к исправлению косяков.

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

В зависимости от организации базы знаний FMS можно поделить на 4 основные категории:
  1. Rule Based: Самый прямолинейный тип. База знаний состоит из набора правил, которые используются для логического вывода
  2. Codebook: оперируют наборами событий которые могут вести к аварии
  3. Нейронные сети: Основу базы знаний составляет предварительно обученная нейронная сеть


Каждый тип систем имеет свои достоинства и недостатки. Rule-based системы склонны к несколько солдафонскому прямолинейному подходу, с другой стороны — они максимально предсказуемы и всегда можно понять, на основании чего система сделала какой-либо вывод. Сodebook Vector иногда показывает лучшие результаты за счет меньшей упертости, но иногда и ошибаются. Нейронные сети способны обучаться, лучше работают в зашумленных условиях или при потерянной части событий. С другой стороны — порой затруднительно понять, в результате какого такого озарения система пришла к конкретному выводу. В целом это порождает некоторую настороженность и взаимное недоверие между оператором и системой. Кроме того, как и все нейронные сети, FMS этого типа склонны внезапно осознавать себя и пытаться захватить власть над миром.

У читателя может возникнуть вполне резонный вопрос — если есть такие чудесные системы, то почему же они не так широко распространены, как обычные системы мониторинга? Почему, особенно в бюджетных инсталляциях, все рвутся ставить нагиосы/заббиксы/кактусы, а про FMS обычно не вспоминают? Ответ на этот вопрос предельно прост — цена! FMS никогда не были дешевым удовольствием. FMS, фактически, это рафинированный чужой опыт, а опыт дорогого стоит. Вторая причина высокой цены — помимо опыта разработчиков приходится покупать и опыт интеграторов, так как с высокой вероятностью придется дополнительно поднастраивать FMS под конкретную сеть.
Типовой бюджет на внедрения FMS обычно содержит шесть и более нулей, что автоматом делает их уделом крупных сетей. Внимательный читатель конечно же скажет — хорошо, но ведь у нас есть open source! Словосочетание open source можно, конечно, повторять как мантру, но во рту от этого слаще не станет. Можно считать, что направление FMS в open-source не представлено.

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

Основная идея, которая привела нас к созданию open-source FMS весьма проста: FMS — это опыт. Сетевики охотно используют open-source продукты и не менее охотно их разрабатывают. Так что же помешает им немного формализовать свой опыт и поделиться с колегами? В результате система приобретает несколько неожиданные свойства, находящиеся уже ближе к социальным сетям. Процесс обучения системы становится распределенным. Кто-то столкнулся с аварией, про которую система не знала, подучил ее, новые правила вошли в общую базу и растеклись со следующими обновлениями всем. На настоящий момент система умеет распознавать около 40 различных типов аварий (Детали можно посмотреть по ссылке). Обучение системы производится на сетях, построенных на базе оборудования Juniper, Force10, Cisco, f5, DLink, Zyxel и поддержка оборудования непрерывно расширяется. По планам, в сентябре месяце выйдет NOC 0.7, который будет включать новый FMS с солидной базой знаний. Надеюсь, что со временем FMS перестанут быть уделом крупных сетей и получат более широкое распространение.

Особенности реализации FMS в NOC будут раскрыты более подробно в следующих статьях.
Теги:NOCFault ManagementmongodbSyslogSNMP
Хабы: Сетевые технологии
Всего голосов 28: ↑28 и ↓0+28
Просмотры15K
Комментарии Комментарии 20

Похожие публикации

Лучшие публикации за сутки