Verkeersmonitoringsystemen in VoIP-netwerken. Deel twee - principes van organisatie

Hallo collega's!

В vorig In het materiaal maakten we kennis met zo'n nuttig en, zoals je kunt zien, een heel noodzakelijk onderdeel van de VoIP-infrastructuur, zoals een verkeersmonitoringsysteem of, kortweg, SMT. We ontdekten wat het is, welke problemen het oplost, en noteerden ook de meest prominente vertegenwoordigers die door ontwikkelaars aan de IT-wereld werden gepresenteerd. In dit deel zullen we de principes bekijken volgens welke SMT wordt geïmplementeerd in de IT-infrastructuur en VoIP-verkeersmonitoring wordt uitgevoerd met behulp van de middelen ervan.

Verkeersmonitoringsystemen in VoIP-netwerken. Deel twee - principes van organisatie

Architectuur van VoIP-verkeersmonitoringsystemen

We bouwden en bouwden en uiteindelijk bouwden we. Hoera!
Uit de tekenfilm "Cheburashka en de krokodil Gena."

Zoals eerder opgemerkt zijn er in de communicatie- en telecommunicatie-industrie genoeg producten die in de juiste categorie vallen. Als we echter abstraheren van de naam, ontwikkelaar, platform, enz., kunnen we zien dat ze allemaal min of meer hetzelfde zijn in termen van hun architectuur (tenminste degene waarmee de auteur te maken kreeg). Het is vermeldenswaard dat dit juist te wijten is aan de eenvoudige afwezigheid van andere methoden om verkeer van netwerkelementen vast te leggen voor de daaropvolgende gedetailleerde analyse. Bovendien wordt dit laatste, naar subjectieve mening, grotendeels bepaald door de huidige ontwikkeling van verschillende gebieden van de betreffende industrie. Voor een beter begrip kunnen we de volgende analogie overwegen.

Vanaf het moment dat de grote Russische wetenschapper Vladimir Aleksandrovitsj Kotelnikov de bemonsteringsstelling creëerde, heeft de mensheid een geweldige kans gekregen om analoog-naar-digitaal en digitaal-naar-analoog conversies van spraaksignalen uit te voeren, waardoor we zo’n prachtig type volledig kunnen gebruiken van communicatie als IP-telefonie. Als je kijkt naar de ontwikkeling van mechanismen voor het verwerken van spraaksignalen (ook wel algoritmen, codecs, coderingsmethoden, enz. genoemd), kun je zien hoe DSP (digitale signaalverwerking) een fundamentele stap heeft gezet in het coderen van informatieberichten: het implementeren van het vermogen om te voorspellen een spraaksignaal. Dat wil zeggen, in plaats van simpelweg te digitaliseren en de a- en u-compressiewetten (G.711A/G.711U) te gebruiken, is het nu mogelijk om slechts een deel van de samples te verzenden en vervolgens het volledige bericht daaruit te herstellen, wat aanzienlijk bespaart bandbreedte. Terugkerend naar het onderwerp MMT merken we op dat er op dit moment geen vergelijkbare kwalitatieve veranderingen zijn in de aanpak van verkeersregistratie, behalve een of ander type spiegeling.

Laten we naar de onderstaande figuur kijken, die illustreert wat er is gebouwd door specialisten op de relevante vakgebieden.

Verkeersmonitoringsystemen in VoIP-netwerken. Deel twee - principes van organisatie
Figuur 1. Algemeen diagram van de SMT-architectuur.

Bijna elke SMT bestaat uit twee hoofdcomponenten: een server en traffic capture-agents (of probes). De server ontvangt, verwerkt en bewaart VoIP-verkeer dat afkomstig is van agenten, en biedt specialisten ook de mogelijkheid om met de ontvangen informatie in verschillende weergaven (grafieken, diagrammen, gespreksstromen, enz.) te werken. Capture-agents ontvangen VoIP-verkeer van netwerkkernapparatuur (bijvoorbeeld SBC, softswitch, gateways, ...), converteren het naar het formaat dat wordt gebruikt in de toegepaste systeemserversoftware en dragen het over naar laatstgenoemde voor daaropvolgende manipulaties.

Net als in muziek creëren componisten variaties op de hoofdmelodieën van werken, dus in dit geval zijn er verschillende opties mogelijk om het bovenstaande schema te implementeren. Hun diversiteit is vrij groot en wordt vooral bepaald door de kenmerken van de infrastructuur waarin MMT wordt ingezet. De meest gebruikelijke optie is een optie waarbij geen capture-agents zijn geïnstalleerd of geconfigureerd. In dit geval wordt het geanalyseerde verkeer rechtstreeks naar de server gestuurd of ontvangt de server bijvoorbeeld de benodigde informatie uit pcap-bestanden die zijn gegenereerd door het monitoren van objecten. Deze leveringsmethode wordt meestal gekozen als het niet mogelijk is om sondes te installeren. De locatie van de apparatuur op de site, het gebrek aan middelen voor virtualisatietools, fouten in de organisatie van het transport-IP-netwerk en, als gevolg daarvan, problemen met netwerkconnectiviteit, enz., dit alles kan de reden zijn om voor de genoemde te kiezen mogelijkheid om monitoring te organiseren.

Nu we hebben geleerd en begrepen hoe deze of gene SMT vanuit architectonisch oogpunt in de IT-infrastructuur kan worden geïmplementeerd, zullen we vervolgens aspecten overwegen die meer binnen de competentie van systeembeheerders vallen, namelijk methoden voor het inzetten van systeemsoftware op servers.

Tijdens de voorbereiding van een besluit over de implementatie van het onderhavige meetnetonderdeel zitten uitvoerders altijd met veel vragen. Wat moet bijvoorbeeld de samenstelling van de serverhardware zijn, is het voldoende om alle systeemcomponenten op één host te installeren of moeten ze van elkaar gescheiden worden, hoe installeer je de software, etc. De hierboven genoemde vragen, evenals vele andere gerelateerde vragen, zijn zeer breed en de antwoorden op veel ervan zijn afhankelijk van de specifieke bedrijfsomstandigheden (of ontwerp). We zullen echter proberen de details samen te vatten om een ​​algemeen idee en begrip te krijgen van dit aspect van de CMT-implementatie.

Het eerste waar specialisten altijd in geïnteresseerd zijn bij het implementeren van SMT, is met welke prestatiekenmerken de server moet worden gebruikt? Gezien het wijdverbreide gebruik van vrije software, wordt deze vraag zo vaak gesteld dat de populariteit ervan waarschijnlijk vergeleken kan worden met de vraag “Wat moet ik doen?”, gesteld door Nikolai Gavrilovich Tsjernysjevski... De belangrijkste factor die het antwoord beïnvloedt, is het aantal mediasessies die door het telefonieplatform worden verwerkt of zullen worden verwerkt. Een numeriek en tastbaar kenmerk dat een specifieke beoordeling van de genoemde factor geeft, is de CAPS-parameter (Call Attempts Per Second), oftewel het aantal oproepen per seconde. De noodzaak om deze vraag te beantwoorden is voornamelijk te wijten aan het feit dat het informatie over sessies is die naar het systeem wordt verzonden die de server belast.

Het tweede probleem dat zich voordoet bij het bepalen van de kenmerken van de hardwarecomponenten van de server is de samenstelling van de software (besturingsomgevingen, databases, enz.) die erop zal functioneren. Signaalverkeer (of mediaverkeer) arriveert bij de server, waar het wordt verwerkt (signaalberichten worden geparseerd) door een toepassing (bijvoorbeeld Kamailio), en vervolgens wordt de op een bepaalde manier gegenereerde informatie in de database geplaatst. Voor verschillende CMT's kunnen zowel de applicaties die de signaaleenheden defragmenteren als de applicaties die opslag bieden verschillend zijn. Ze zijn echter allemaal verenigd door dezelfde aard van multithreading. Tegelijkertijd moet er, vanwege de eigenaardigheden van een dergelijk infrastructuurelement als SMT, op dit punt worden opgemerkt dat het aantal schrijfbewerkingen naar de schijf aanzienlijk groter is dan het aantal leesbewerkingen ervan.

En tot slot... “Er zit zoveel in dit woord”: server, virtualisatie, containerisatie... Het laatste, maar zeer belangrijke aspect dat in dit deel van het artikel wordt besproken, zijn de mogelijke manieren om MMT-componenten te installeren tijdens de implementatie ervan. Vermeld naast een citaat uit het onsterfelijke werk van A.S. Pushkin-technologieën worden veel gebruikt in verschillende infrastructuren en projecten. Enerzijds zijn ze nauw met elkaar verbonden, anderzijds verschillen ze op veel criteria opvallend van elkaar. Ze worden echter allemaal, in een of andere vorm, door ontwikkelaars gepresenteerd als beschikbare opties voor het installeren van hun producten. Als we de systemen in het eerste deel van het artikel samenvatten, merken we de volgende methoden op om ze op een fysieke server of virtuele machine te implementeren:
— gebruik van automatische installatiescripts of zelfinstallatie en daaropvolgende configuratie van de bijbehorende software,
— gebruik van een kant-en-klaar besturingssysteemimage met vooraf geïnstalleerde SMT-software en/of agent,
— gebruik van containerisatietechnologie (Docker).

De genoemde installatietools hebben hun voor- en nadelen, en specialisten hebben hun eigen voorkeuren, beperkingen en specifieke omstandigheden waarin de infrastructuur die zij exploiteren of implementeren zich bevindt om eventuele aanbevelingen te kunnen uiten. Aan de andere kant is de gegeven beschrijving van manieren om SIP-verkeersmonitoringsystemen in te zetten vrij transparant en vereist deze in de huidige fase geen gedetailleerdere overweging.

Dit is een ander artikel gewijd aan een belangrijk en interessant element van het VoIP-netwerk: het SIP-verkeersmonitoringsysteem. Zoals altijd dank ik de lezers voor hun aandacht voor dit materiaal! In het volgende deel zullen we proberen nog dieper op de details in te gaan en de HOMER SIP Capture- en SIP3-producten te bekijken.

Bron: www.habr.com

Voeg een reactie