Итак, зачем это нужно? Представим себе компанию, имеющую представительства в основных крупных городах нашей необъятной родины. Связь между офисами осуществляется через публичные сети (Internet) и с использованием выделенной операторской сети (MPLS). Для обеспечения безопасности поверх этих сетей «подняты» VPN-туннели в которых собственно и передаются данные. Плюс ко всему, для повышения надежности (отказоустойчивости сети) одновременно используются один основной (MPLS) и два резервных (Internet) виртуальных каналов передачи данных; в случае отказов каналов маршрутизация обеспечивается с помощью OSPF (в случае отказа одного из каналов трафик будет маршрутизироваться по другому каналу). Как показала практика, даже при такой, казалось бы, надежной схеме, возможны нарушения связи. И в том случае, если клиентские компьютеры работают с использованием RDP, а внутренняя телефонная связь компании осуществляется по VoIP работа удаленного офиса становится невозможной.

Вообще, помимо нарушений, негативное влияние на realtime-сервисы (RDP, VoIP, видеоконференции) оказывают потери пакетов, а также так называемый джиттер (Jitter) – разница во времени доставки пакетов.

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

Чтобы не быть голословным, приведу реальные цифры для компании, имеющей 20 региональных офисов и соединенных с центральным 3-мя каналами каждый, т.е. всего около 60 каналов. Мониторить и фиксировать нарушения (длительностью более 30 минут) мы начали 17 марта. Итак: за 15 дней марта всего было зафиксированно 40 нарушений, из них в 6 случаях создавалась заявка провайдерам, а в 3-х случаях нарушения негативно влияли на пользователей. По итогам апреля всего зафиксирован 51 случай, отправлено 22 заявки и лишь в 2-х случаях пользователи могли это заметить. В мае за 20 дней зафиксированно 16 случаев нарушения каналов, 8 заявок и ни одного случая, способного повлиять на пользователей. На графике представлено среднее количество нарушений за один день по месяцам:

graph

Разница в количестве нарушений и отправленных заявок объясняется не круглосуточным режимом работы оператора и сетевого отдела. Видно, что с начала мониторинга и ведения статистики, общее количество нарушений заметно поубавилось. Ну не хотят провайдеры терять клиетов, зная что качество их сервиса отслеживается…;) А может мне это просто показалось…

Как это работает? Оператор получает алерт о нарушении конкретного канала путем SMS-сообщения, Email или видит его в консоли SCOMa:

sms

email

alert_console

Время между самим нарушением и созданием (отправкой) алерта не превышает 4х минут. Обусловленно это техническими особенностями, а также защитой от «дребезга» поскольку весьма часто случаются кратковременные нарушения.

После получения алерта в котором содержится название конкретного канала оператору остается выбрать регион (в консоли SCOM):

regions

Далее открывается окно, в котором в виде графиков собраны с десяток параметров:

region_view

Компоновка графиков получена опытным путем на действующей сети, как наиболее удобной для восприятия и способствует скорейшей диагностике проблемы «за один клик». Рассмотрим поподробней данный скриншот. Графики 1 и 2 показывают состояние маршрутизатора (загрузка процессора, оперативной памяти и памяти буфера) с целью исключения возможного влияния на работу каналов. На 3-м графике представлено значение RTT для интегрального канала, т.е. текущего соединения между регионом и центральным офисом «глазами пользователя». На 4-м графике в положительной зоне оси Y мы видим количество потерянных пакетов для всех каналов региона. В отрицательной зоне – код состояния, отличного от нормального. В данном случае это -6, что значит нарушение канала. Различные по типу каналы выделены разными цветами: интегральный – красный; MPLS – синий; два резервных публичных канала – зеленый и желтый. Здесь с качеством каналов все хорошо, потерь не наблюдается. 5-й график показывает скорость туннельных интерфейсов. Видно, что при нарушении основного канала трафик «уходит» на резервный. На 6-м графике значения RTT для MPLS и публичных каналов, кроме интегрального.

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

stat

А с Ростовом все хорошо, нарушение оказалось не длительным, инженер сетевого отдела был предупрежден о нарушении, но не успел даже «залезть в циску» как пришло сообщение о восстановлении..:) К счастью, чаще всего так и случается..

sms_closed

email_closed

scom_alert_closed

Что касается потерь пакетов в каналах – всё работает аналогично.
Ну и конечно, нельзя не упомянуть, что все гибко настраивается и переопределяется.

P.S. Напоследок, представлю наиболее интересные скриншоты с реальными ситуациями. Вот так у нас работают иногда провайдеры))) Без комментариев..

igevsk_20022009

perm_100409_public_integral

А вот здесь сотрудник, видать, решил качнуть кинцо…

eburg_250309