Trafikovervågningssystemer i VoIP-netværk. Anden del - principper for organisation

Hej kolleger!

В Tidligere I materialet stiftede vi bekendtskab med et så nyttigt og, som du kan se, ganske nødvendigt element i VoIP-infrastrukturen, såsom et trafikovervågningssystem eller kort sagt SMT. Vi fandt ud af, hvad det er, hvilke problemer det løser, og bemærkede også de mest fremtrædende repræsentanter, som udviklere præsenterede for IT-verdenen. I denne del vil vi overveje de principper, hvorefter SMT implementeres i IT-infrastrukturen, og VoIP-trafikovervågning udføres ved hjælp af dets midler.

Trafikovervågningssystemer i VoIP-netværk. Anden del - principper for organisation

Arkitektur af VoIP trafikovervågningssystemer

Vi byggede og byggede og til sidst byggede vi. Hurra!
Fra tegnefilmen "Cheburashka and the Crocodile Gena."

Som tidligere nævnt er der nok produkter i kommunikations- og telekommunikationsindustrien, der falder ind under den tilsvarende kategori. Men hvis vi abstraherer fra navnet, udvikleren, platformen osv., kan vi se, at de alle er nogenlunde ens med hensyn til deres arkitektur (i hvert fald dem, forfatteren skulle forholde sig til). Det er værd at bemærke, at dette netop skyldes det simple fravær af andre metoder til at fange trafik fra netværkselementer til dens efterfølgende detaljerede analyse. Desuden er sidstnævnte efter subjektiv mening i vid udstrækning bestemt af den aktuelle udvikling af forskellige områder af fagbranchen. For en klarere forståelse, overvej følgende analogi.

Fra det øjeblik, den store russiske videnskabsmand Vladimir Aleksandrovich Kotelnikov skabte prøvetagningssætningen, har menneskeheden fået en enorm mulighed for at udføre analog-til-digital og digital-til-analog konverteringer af talesignaler, takket være hvilken vi fuldt ud kan bruge sådan en vidunderlig type af kommunikation som IP-telefoni. Hvis man ser på udviklingen af ​​mekanismer til behandling af talesignaler (alias algoritmer, codecs, indkodningsmetoder osv.), kan man se, hvordan DSP (digital signalbehandling) har taget et fundamentalt skridt i kodningen af ​​informationsmeddelelser - implementerer evnen til at forudsige et talesignal. Det vil sige, at i stedet for blot at digitalisere og bruge a- og u-love for kompression (G.711A/G.711U), er det nu muligt kun at transmittere en del af samplerne og derefter gendanne hele meddelelsen fra dem, hvilket sparer betydeligt båndbredde. For at vende tilbage til emnet MMT, bemærker vi, at der i øjeblikket ikke er nogen lignende kvalitative ændringer i tilgangen til trafikfangst, bortset fra en eller anden type spejling.

Lad os se på nedenstående figur, som illustrerer, hvad der blev bygget af specialister inden for de relevante fagområder.

Trafikovervågningssystemer i VoIP-netværk. Anden del - principper for organisation
Figur 1. Generelt diagram over SMT-arkitekturen.

Næsten enhver SMT består af to hovedkomponenter: en server og trafikfangstagenter (eller prober). Serveren modtager, behandler og lagrer VoIP-trafik, der kommer fra agenter, og giver også specialister mulighed for at arbejde med den modtagne information i forskellige visninger (grafer, diagrammer, Call Flow, osv.). Capture-agenter modtager VoIP-trafik fra netværkets kerneudstyr (f.eks. SBC, softswitch, gateways,...), konverterer det til det format, der bruges i den anvendte systemserversoftware, og overfører det til sidstnævnte til efterfølgende manipulationer.

Ligesom i musik skaber komponister variationer af de vigtigste melodier af værker, så i dette tilfælde er forskellige muligheder for at implementere ovenstående ordning mulige. Deres mangfoldighed er ret stor og bestemmes hovedsageligt af egenskaberne ved den infrastruktur, hvori MMT er indsat. Den mest almindelige mulighed er en, hvor ingen capture-agenter er installeret eller konfigureret. I dette tilfælde sendes den analyserede trafik direkte til serveren, eller serveren modtager f.eks. den nødvendige information fra pcap-filer genereret af overvågningsobjekter. Denne leveringsmetode vælges normalt, hvis det ikke er muligt at installere sonder. Placeringen af ​​udstyret på webstedet, manglen på ressourcer til virtualiseringsværktøjer, fejl i organisationen af ​​transport-IP-netværket og som et resultat problemer med netværksforbindelse osv., alt dette kan være årsagen til at vælge det noterede mulighed for at organisere overvågning.

Efter at have lært og forstået, hvordan denne eller hin SMT kan implementeres i IT-infrastrukturen fra et arkitektonisk synspunkt, vil vi herefter overveje aspekter, der er mere inden for systemadministratorernes kompetence, nemlig metoder til at implementere systemsoftware på servere.

Under udarbejdelsen af ​​en beslutning om implementering af den overvågningsnetværkskomponent, der overvejes, har implementere altid mange spørgsmål. For eksempel hvad skal sammensætningen af ​​serverhardwaren være, er det tilstrækkeligt at installere alle systemkomponenter på én vært eller skal de være adskilt fra hinanden, hvordan installeres softwaren osv. Spørgsmålene nævnt ovenfor, såvel som mange andre relaterede spørgsmål, er meget brede, og svarene på mange af dem afhænger virkelig af de specifikke driftsforhold (eller design). Vi vil dog forsøge at opsummere detaljerne for at få en generel idé og forståelse af dette aspekt af CMT-udrulningen.

Så den første ting, som specialister altid er interesserede i, når de implementerer SMT, er hvilke ydeevneegenskaber skal serveren bruges med? I betragtning af den udbredte brug af gratis software bliver dette spørgsmål stillet så mange gange, at dets popularitet sandsynligvis kan sammenlignes med spørgsmålet "Hvad skal jeg gøre?" stillet af Nikolai Gavrilovich Chernyshevsky... Den vigtigste faktor, der påvirker svaret, er antallet af mediesessioner, der behandles eller vil blive behandlet af telefoniplatformen. En numerisk og håndgribelig egenskab, der giver en specifik vurdering af den noterede faktor, er CAPS-parameteren (Call Attempts Per Second) eller antallet af opkald pr. sekund. Behovet for at besvare dette spørgsmål skyldes primært, at det er information om sessioner sendt til systemet, der vil skabe en belastning på dets server.

Det andet problem, der opstår, når man beslutter sig for egenskaberne af serverens hardwarekomponenter, er sammensætningen af ​​softwaren (driftsmiljøer, databaser osv.), der vil fungere på den. Signal- (eller medie-) trafik ankommer til serveren, hvor den behandles (signalbeskeder parses) af en applikation (f.eks. Kamailio), og derefter placeres informationen, der genereres på en bestemt måde, i databasen. For forskellige CMT'er kan både applikationerne, der defragmenterer signalenhederne, og applikationerne, der leverer lager, være forskellige. Imidlertid er de alle forenet af den samme karakter af multithreading. På samme tid, på grund af ejendommelighederne ved et sådant infrastrukturelement som SMT, skal det på dette tidspunkt bemærkes, at antallet af skriveoperationer til disken væsentligt overstiger antallet af læseoperationer fra den.

Og til sidst... "Der er så meget i dette ord": server, virtualisering, containerisering... Det sidste, men meget vigtige aspekt, der berøres i denne del af artiklen, er de mulige måder at installere MMT-komponenter på under deres udrulning. Opført ved siden af ​​et citat fra det udødelige værk af A.S. Pushkin-teknologier er meget udbredt i forskellige infrastrukturer og projekter. På den ene side er de tæt forbundet med hinanden, og på den anden side adskiller de sig påfaldende i mange kriterier. Men alle af dem, i en eller anden form, præsenteres af udviklere som tilgængelige muligheder for at installere deres produkter. Sammenfattende systemerne, der er anført i den første del af artiklen, bemærker vi følgende metoder til at implementere dem på en fysisk server eller virtuel maskine:
— brug af automatiske installationsscripts eller selvinstallation og efterfølgende konfiguration af den tilsvarende software
— brug af et færdigt OS-image med forudinstalleret SMT-software og/eller agent
— anvendelse af containeriseringsteknologi (Docker).

De anførte installationsværktøjer har deres fordele og ulemper, og specialister har deres egne præferencer, begrænsninger og specifikke forhold, hvori den infrastruktur, de driver eller implementerer, er placeret for at fremsætte eventuelle anbefalinger. På den anden side er den givne beskrivelse af måder at implementere SIP trafikovervågningssystemer ret gennemskuelig på og kræver på nuværende tidspunkt ikke en mere detaljeret overvejelse.

Dette er endnu en artikel om et vigtigt og interessant element i VoIP-netværket - SIP-trafikovervågningssystemet. Som altid takker jeg læserne for deres opmærksomhed på dette materiale! I den næste del vil vi forsøge at gå endnu dybere ind i detaljerne og se på HOMER SIP Capture og SIP3 produkterne.

Kilde: www.habr.com

Tilføj en kommentar