Развитие современных телекоммуникационных сетей поражает: от сигнальных костров они шагнули далеко вперёд, и то, что казалось немыслимым ранее, сейчас является простым и обыденным. И только профессионалы знают, что скрывается за повседневностью и широким использованием достижений отрасли информационных технологий. Разнообразие сред передачи, способов коммутации, протоколов взаимодействия устройств и алгоритмов кодирования поражает сознание обывателя и может стать настоящим кошмаром для любого, кто связан с их исправным и стабильным функционированием: прохождение тональных сигналов или голосового трафика, невозможность регистрации на softswitch, тестирование нового оборудования, составление обращения в support вендора.
Упомянутое выше понятие протокола – это краеугольный камень любой сети связи, от которого будет зависеть её архитектура, состав и сложность составляющих её устройств, перечень предоставляемых ею услуг и многое другое. При этом, очевидной, но очень важной является закономерность, заключающаяся в том, что использование более гибкого протокола сигнализации улучшает масштабируемость сети связи, что влечёт за собой достаточно быстрое увеличение в ней различных сетевых устройств.
При этом даже необходимое и оправданное наращивание числа взаимосвязанных сетевых элементов в рамках отмеченной закономерности влечёт за собой ряд сложностей, связанных с сопровождением сети и её эксплуатацией. Многие специалисты сталкивались с ситуацией, когда снятый дамп не позволяет однозначно локализовать возникшую проблему, т.к. был получен на том участке сети, который не причастен к её появлению.
Такая ситуация особенно характерна для VoIP-сетей, которые включают в себя количество устройств большее, чем одна PBX и несколько IP-телефонов. Например, когда в решении используются несколько пограничных контроллеров сессий, гибких коммутаторов или softswitch один, но функция определения местоположения пользователя отделена от прочих и вынесена на отдельное устройство. Тогда инженеру приходится выбирать для анализа следующий участок, руководствуясь своим эмпирическим опытом или волей случая.
Такой подход крайне утомителен и не продуктивен, так как вынуждает из раза в раз тратить время на борьбу с одними и теми же вопросами: что получится использовать для сбора пакетов, как забрать результат и так далее. С одной стороны, как известно, человек привыкает ко всему. К этому также можно привыкнуть, «набить руку» и натренировать терпение. Однако с другой стороны всё равно присутствует ещё одна сложность, с которой нельзя не считаться – корреляция трассировок, взятых с разных участков. Все вышеперечисленные, а также многие другие задачи анализа сетей связи составляет предмет деятельности многих специалистов, помочь решить которые призваны системы мониторинга трафика.
О системах мониторинга трафика сетей связи
А вместе — делаем общее дело: ты по-своему, а я по-своему.
Ю. Деточкин
Современные сети передачи медиатрафика проектируются и строятся посредством реализации различных концепций, фундамент которых составляет множество телекоммуникационных протоколов: CAS, SS7, INAP, H.323, SIP и т.д. Система мониторинга трафика (СМТ) – это средство, которое призвано производить захват сообщений, перечисленных выше (и не только) протоколов, и обладает набором удобных, интуитивно понятных и информативных интерфейсов для его анализа. Основное назначение СМТ – сделать сигнальные трассировки и дампы за любой промежуток времени доступными для специалистов в любое время (в том числе в режиме реального времени) без использования специализированных программ (например, Wireshark). С другой стороны, каждый квалифицированный специалист обращает пристальное внимание на вопросы, связанные, например, с безопасностью ИТ-инфраструктуры.
При этом немаловажным аспектом, напрямую связанным с данным вопросом, является возможность данного специалиста «держать руку на пульсе», что может быть достигнуто в том числе с помощью своевременного оповещения о том или ином инциденте. Коль скоро упомянуто о вопросах оповещения, то мы говорим о мониторинге сети связи. Возвращаясь к приведённому выше определению, СМТ позволяет выполнять контроль тех сообщений, ответов и активностей, которые могут свидетельствовать о каком-либо аномальном поведении сети (например, ответы 403 или 408 группы 4хх в SIP или резкое увеличение числа сессий на транке), при этом получить соответствующую инфографику, которая наглядно иллюстрирует происходящее.
Однако следует отметить, что система мониторинга трафика VoIP изначально не является той классической Fault Monitoring System, которая позволяет составлять карты сетей, контролировать доступность их элементов, утилизацию ресурсов, периферию и многое другое (например, как Zabbix).
Разобравшись с тем, что представляет собой система мониторинга трафика, и задачах, которые она решает, перейдём к вопросу о том, как же её применить с пользой для дела.
Очевидным является тот факт, что сама по себе СМТ не способна собрать Call Flow «по щучьему велению». Для этого необходимо свести соответствующий трафик со всех используемых устройств в одну точку – Capture Server. Таким образом, написанное определяет характерную особенность системы, которая выражается в необходимости обеспечения централизации места сбора сигнального трафика и позволяет ответить на поставленный выше вопрос: что даёт использование комплекса на эксплуатируемой или внедряемой сети.
Итак, как правило, редко инженер может, что называется, с ходу ответить на вопрос — в каком конкретном месте будет или может находится указанная точка централизации трафика. Для более-менее однозначного ответа специалистам необходимо провести ряд изысканий, связанных с предметным анализом VoIP-сети. Например, повторное уточнение состава оборудования, детальное определение точек его включения, а также возможностей в контексте отправки соответствующего трафика в точку сбора. Кроме того, ясно, что успешность решения рассматриваемого вопроса напрямую зависит от способа организации транспортной IP-сети.
Следовательно, первое, что даёт внедрение СМТ – это та самая, когда-то запланированная, но так и не выполненная ревизия сети. Конечно, вдумчивый читатель сразу задаст вопрос – а при чём тут СМТ? Прямой связи здесь нет и быть не может, но … Психология большинства людей, в том числе и тех, кто связан с миром ИТ, обычно склонна приурочивать такого рода мероприятия к какому-либо событию. Следующий плюс вытекает из предыдущего и заключается в том, что ещё до того, как будет развёрнута СМТ, установлены и настроены Capture Agents, включена отправка RTCP сообщений, вполне могут быть обнаружены какие-либо проблемы, требующие оперативного вмешательства. Например, где-то образовалось «бутылочное горлышко» и это явно видно и без статистики, которую в том числе может предоставлять СМТ, используя данные, предоставляемые, например, RTCP.
Теперь вернёмся к описанному ранее процессу сбора так необходимых нам трассировок и улыбнёмся, вспомнив слова героя, вынесенные в эпиграф данной части. Важной его особенностью, которая не была указана, является то, что, как правило, перечисленные манипуляции может производить персонал достаточной квалификации, например, Core Engineers. С другой стороны, в круг вопросов, решаемых с помощью трассировок, могут входить и так называемые рутинные задачи. Например, определение причины, по которой не регистрируется терминал у инсталлятора или клиента. При этом, становится очевидным, что наличие исключительной возможности снятия дампов у отмеченных специалистов накладывает на них необходимость выполнения данных производственных задач. Это не продуктивно по причине того, что отнимает время от решения других более важных вопросов.
При этом в большинстве компаний, где желательно использование такого продукта, как СМТ, имеется специальное подразделение, в список задач которого как раз и входит выполнение рутинных операций, с целью разгрузки других специалистов – service desk, helpdesk или техническая поддержка. Также я не сделаю для читателя открытие, если отмечу, что доступ инженеров службы технической поддержки из соображений безопасности и стабильности сети к наиболее критичным узлам нежелателен (хотя вполне возможно, что он и не возбраняется), а ведь именно указанные сетевые элементы содержат наиболее выгодный ракурс с точки зрения дампов. СМТ, ввиду того, что является центральным местом сбора трафика и обладает интуитивным и прозрачным интерфейсом, вполне способен решить ряд обозначенных проблем. Единственное условие – организация доступа к интерфейсу с рабочих мест специалистов технической поддержки и, возможно, написание knowledge base статьи по её использованию.
В заключение отметим наиболее известные и интересные продукты, так или иначе выполняющие рассмотренный выше функционал, среди которых: Voipmonitor, HOMER SIP Capture, Oracle Communications Monitor, СПАЙДЕР. Несмотря на имеющийся общий подход к организации и развёртыванию, каждая имеет свои нюансы, субъективные положительные и отрицательные стороны и все заслуживают их отдельного рассмотрения. Что и станет предметом дальнейших материалов. Спасибо за Ваше внимание!
Комментариев нет:
Отправить комментарий