Системы мониторинга трафика в сетях VoIP. Часть вторая — принципы организации

Здравствуйте, коллеги!

В предыдущем материале мы познакомились с таким полезным и, как можно заметить, достаточно необходимым элементом VoIP-инфраструктуры, как система мониторинга трафика или, для краткости, СМТ. Узнали, что это такое, какие задачи решает, а также отметили наиболее ярких представителей, представленных разработчиками миру ИТ. В данной части рассмотрим принципы, согласно которым осуществляется внедрение СМТ в ИТ-инфраструктуру и мониторинг трафика VoIP её средствами.

Архитектура систем мониторинга VoIP-трафика

Мы строили, строили и наконец построили. Ура!
Из мультфильма «Чебурашка и крокодил Гена».

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

С того момента, как великий русский учёный Владимир Александрович Котельников создал теорему отсчётов, человечество получило грандиозную возможность выполнять аналого-цифровое и цифро-аналоговое преобразования речевых сигналов, благодаря которому, мы можем в полной мере использовать такой замечательный вид связи как IP-телефония. Если взглянуть на развитие механизмов обработки речевых сигналов (aka алгоритмы, кодеки, способы кодирования etc.), то можно заметить, как ЦОС (цифровая обработка сигналов) сделала принципиальный шаг в кодировании информационных сообщений – реализация возможности предсказания речевого сигнала. То есть, вместо просто оцифровки и использования a- и u-законов сжатия (G.711A/G.711U), теперь имеется возможность передачи лишь части отсчётов с последующим восстановлением из них всего сообщения, что существенно экономит полосу. Возвращаясь к теме СМТ, отметим, что на текущий момент аналогичных качественных изменений в подходе к захвату трафика, кроме того или иного вида зеркалирования, нет.

Обратимся к рисунку, приведённому далее и иллюстрирующему то, что же было построено специалистами соответствующих предметных областей.

Рисунок 1. Общая схема архитектуры СМТ.

Практически любая СМТ состоит из двух основных компонентов: сервера и агентов захвата трафика (или пробников). Сервер выполняет приём, обработку и хранение VoIP-трафика, который поступает от агентов, а также предоставляет специалистам возможность работы с получаемой информацией в различных представлениях (графики, диаграммы, Call Flow, etc). Агенты захвата осуществляют приём VoIP-трафика от оборудования ядра сети (например, SBC, softswitch, шлюзы,..), преобразование его в формат, используемый в применяемом программном обеспечении сервера системы, и передачу его последнему для последующих манипуляций.

Как в музыке композиторы создают вариации на основные мелодии произведений, так и в данном случае возможны различные варианты реализации приведённой схемы. Их многообразие достаточно велико и в основном определяется характеристиками инфраструктуры, в которой разворачивается СМТ. Наиболее часто встречающимся вариантом является тот, при котором не устанавливаются и не настраиваются агенты захвата. В данном случае анализируемый трафик направляется напрямую к серверу или, например, сервер получает необходимую информацию из pcap-файлов, сформированных объектами мониторинга. Такой способ доставки, как правило, выбирается в случае, если отсутствует возможность установки пробников. Место на площадке размещения оборудования, нехватка ресурсов средств виртуализации, изъяны в организации транспортной IP-сети и, как следствие, проблемы с сетевой связностью и т.д., всё это может являться причиной выбора отмеченного варианта организации мониторинга.

Узнав и разобравшись, как та или иная СМТ может быть внедрена в IT-инфраструктуру с архитектурной точки зрения, далее рассмотрим аспекты, более входящие в компетенцию системных администраторов, а именно, способы развёртывания программного обеспечения систем на серверах.

В ходе подготовке решения по реализации рассматриваемого компонента сети мониторинга у исполнителей всегда возникает много вопросов. Например, каков должен быть состав аппаратного обеспечения сервера, достаточна ли установка всех компонентов системы на одном хосте или стоит отделить их друг от друга, каким образом выполнять установку программного обеспечения, etc. Перечисленные выше, а также многие другие смежные вопросы, очень обширны, а ответы на многие из них действительно зависят от конкретных условий эксплуатации (или проектировки). Однако постараемся обобщить конкретику, чтобы получить общее представление и понимание данной стороны деплоя СМТ.

Итак, первое, что всегда интересует специалистов при реализации СМТ – с какими ТТХ использовать сервер? Учитывая широкое распространение свободного программного обеспечения, данный вопрос задаётся столько раз, что по популярности его, наверное, можно сравнить с вопросом «Что делать?», заданным ещё Николаем Гавриловичем Чернышевским… Основным фактором, влияющим на ответ, является количество медиасессий, которое обрабатывается или будет обрабатываться платформой телефонии. Численная и осязаемая характеристика, дающая конкретную оценку отмеченного фактора, — это параметр CAPS (Call Attempts Per Second) или количество вызовов в секунду. Необходимость ответа на данный вопрос в первую очередь обусловлен тем, что именно информация о сессиях, направленная в систему, и будет создавать нагрузку на её сервер.

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

И наконец… «Как много в этом слове»: сервер, виртуализация, контейнеризация… Последний, но очень важный аспект, затронутый в данной части статьи, – это возможные способы установки компонентов СМТ при её развёртывании. Перечисленные рядом с цитатой из бессмертного произведения А.С. Пушкина технологии, широко распространены в различных инфраструктурах и проектах. С одной стороны, они тесно взаимосвязаны друг с другом, а с другой – разительно отличаются по многим критериям. Тем не менее, все они, в том или ином виде, представлены разработчиками в качестве доступных вариантов для установки своих продуктов. Обобщая для перечисленных в первой части статьи систем, отметим следующие способы их развёртывания на физический сервер или виртуальную машину:
— использование сценариев автоматической установки или самостоятельная установка и последующая настройка соответствующего программного обеспечения,
— использование готового образа ОС с предустановленным ПО СМТ и/или агента,
— использование технологии контейнеризации (Docker).

Перечисленные средства установки имеют свои достоинства и недостатки, а у специалистов имеются свои предпочтения, ограничения и конкретные условия, в которых находится эксплуатируемая или внедряемая ими инфраструктура, для того, чтобы озвучивать какие-либо рекомендации. С другой стороны, приведённое описание путей развёртывания систем мониторинга SIP-трафика достаточно прозрачно, и на текущем этапе не требует его более детального рассмотрения.

Такой получилась ещё одна статья, посвящённая важному и интересному элементу VoIP-сети – системе мониторинга SIP-трафика. Как всегда, благодарю читателей за проявленное внимание к данному материалу! В следующей части постараемся ещё больше углубиться в конкретику и рассмотреть продукты HOMER SIP Capture и SIP3.

Источник: habr.com