Вітаю колеги!
В Ми познайомилися з таким корисним і, як можна помітити, досить необхідним елементом 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