Hej kolleger!
I I det tidligere materiale blev vi introduceret til et så nyttigt og, som man kan se, temmelig nødvendigt element af VoIP-infrastrukturen, som er trafikovervågningssystemet eller, for kortheds skyld, TOS. Vi lærte, hvad det er, hvilke opgaver det løser, samt bemærkede de mest markante repræsentanter, der er præsenteret af udviklerne til IT-verdenen. I denne del vil vi se nærmere på de principper, ifølge hvilke implementeringen af TOS i IT-infrastrukturen og overvågningen af VoIP-trafik udføres.
Arkitektur af VoIP-trafikovervågningssystemer
Vi byggede, byggede og endelig byggede vi. Hurra!
Fra tegnefilmen 'Tje Burashka og krokodille Gena'.
Som tidligere nævnt er der i telekommunikationsbranchen et tilstrækkeligt antal produkter, der tilhører den tilsvarende kategori. Men hvis vi abstraherer fra navnet, udvikleren, platformen osv., kan vi bemærke, at de alle er mere eller mindre ensartede med hensyn til deres arkitektur (i det mindste dem, som forfatteren har haft erfaring med). Det er værd at bemærke, at dette skyldes det enkle fravær af alternative metoder til at opsamle trafik fra netværkselementer for at analysere det i detalje. Dette sidste, efter en subjektiv mening, er i højere grad bestemt af den aktuelle udvikling inden for forskellige områder af den relevante industri. For en klarere forståelse vil vi overveje følgende analogi.
Siden den store russiske videnskabsmand Vladimir Aleksandrovich Kotelnikov skabte teorien om målepunkter, har menneskeheden fået en fantastisk mulighed for at udføre analog-til-digital og digital-til-analog konvertering af talesignaler, hvilket gør det muligt for os at udnytte den vidunderlige kommunikationsform som IP-telefoni fuldt ud. Ser vi på udviklingen af mekanismerne til behandling af talesignaler (fx algoritmer, codecs, kodningsmetoder osv.), kan vi se, hvordan DSP (digital signalbehandling) har taget et principielt skridt fremad i kodningen af informationsmeddelelser – implementeringen af muligheden for at forudsige talesignalet. Det vil sige, at i stedet for blot at digitalisere og anvende a- og u-lofterne for komprimering (G.711A/G.711U), er det nu muligt kun at overføre en del af målepunkterne, hvorefter hele meddelelsen kan genskabes, hvilket sparer en betydelig mængde båndbredde. Når vi vender tilbage til emnet SMT, skal vi bemærke, at der i øjeblikket ikke findes lignende kvalitetsændringer i tilgangen til trafikfangst, udover forskellige former for spejling.
Lad os se på det diagram, der følger, og som illustrerer, hvad der er blevet opbygget af specialister inden for de relevante fagområder.
Figur 1. Den generelle arkitektur for SMT.
Næsten enhver SMT består af to hovedkomponenter: en server og trafikfangstagenter (eller probes). Serveren modtager, behandler og opbevarer VoIP-trafikken, der kommer fra agenterne, samt giver specialister mulighed for at arbejde med de modtagne oplysninger i forskellige fremstillinger (grafer, diagrammer, Call Flow osv.). Trafikfangstagenterne registrerer VoIP-trafikken fra netværkets kerneudstyr (f.eks. SBC, softswitch, gateways osv.), konverterer den til det format, der anvendes af serversoftwaren, og sender den til sidst til serveren for efterfølgende manipulation.
Ligesom komponister skaber variationer over hovedmelodier i musik, er der i dette tilfælde også forskellige måder at implementere den nævnte skema. Deres mangfoldighed er ganske stor og bestemmes hovedsageligt af karakteristikaene for den infrastruktur, hvor SMT implementeres. Den mest almindelige variant er den, hvor der ikke installeres eller konfigureres indfangningsagenter. I dette tilfælde dirigeres den analyserede trafik direkte til server eller for eksempel, at serveren modtager de nødvendige oplysninger fra pcap-filer dannet af monitoreringsobjekter. Denne leveringsmetode vælges normalt, hvis det ikke er muligt at installere sensorer. Pladsen på udstyrssite, mangel på ressourcer til virtualisering, mangler i den transporterede IP-netværksorganisation og som følge heraf problemer med netværksforbindelse osv. kan alle være grunde til at vælge den nævnte variant af monitoreringsorganisation.
Efter at have forstået, hvordan en given SMT kan implementeres i IT-infrastrukturen fra et arkitektonisk synspunkt, vil vi nu se på aspekter, der mere falder ind under systemadministratorernes kompetence, nemlig måder at deployere systemsoftware på servere.
Under forberedelsen af løsningen til implementering af den nævnte komponent i monitoreringsnetværket opstår der altid mange spørgsmål for udførende. For eksempel, hvad skal sammensætningen af serverens hardware være, er det tilstrækkeligt at installere alle systemkomponenter på én vært, eller er det bedre at adskille dem fra hinanden, hvordan skal installationen af software udføres osv. De ovennævnte samt mange andre relaterede spørgsmål er meget omfattende, og svarene på mange af dem afhænger faktisk af de specifikke driftsbetingelser (eller designforhold). Men lad os forsøge at sammenfatte detaljerne for at få en generel forståelse af denne side af SMT-deployeringen.
Det første, som altid interesserer fagfolkene ved implementering af SMT, er, hvilke tekniske specifikationer der skal bruges til serveren. Givet den udbredte brug af open source-software, bliver dette spørgsmål stillet så ofte, at det næsten kan sammenlignes med spørgsmålet 'Hvad skal man gøre?', stillet af Nikolaj Gavrilovitj Tjernysjevskij... Den primære faktor, der påvirker svaret, er antal mediesessioner, som telekommunikationsplatformen behandler eller vil behandle. Den numeriske og håndgribelige karakteristik, der giver en konkret vurdering af denne faktor, er CAPS (Call Attempts Per Second) eller antal opkald pr. sekund. Behovet for at besvare dette spørgsmål skyldes primært, at det netop er informationen om sessionerne, der sendes til systemet, som vil belaste serveren.
Det andet spørgsmål, der opstår under beslutningsprocessen om serverens hardwarekomponenters specifikationer, er sammensætningen af den software (driftsmiljøer, databaser osv.), der vil fungere på den. Signalerings- (eller medietrafik) leveres til serveren, hvor den behandles (analyse af signalbeskeder) af et givent program (f.eks. Kamailio), hvorefter de på en bestemt måde dannede oplysninger placeres i databasen. For forskellige SMT'er, både applikationer, der udfører defragmentering af signalenheder, og applikationer, der muliggør lagring, kan variere. Alligevel er de alle forenet af en fælles natur af multitrådning. På grund af karakteristika for dette infrastrukturkomponent, såsom SMT, bør det i denne sammenhæng bemærkes, at antallet af skriveoperationer til disk betydeligt overstiger antallet af læseoperationer fra den.
Og til sidst... "Hvor meget der er i dette ord": server, virtualisering, containerisering... Den sidste, men meget vigtige aspekt, der berøres i denne del af artiklen, er de mulige måder at installere SMT-komponenter ved dens implementering. Teknologierne nævnt ved siden af citatet fra det tidløse værk af A.S. Pushkin er bredt udbredt i forskellige infrastrukturer og projekter. På den ene side er de nært forbundet med hinanden, mens de på den anden side adskiller sig markant på mange kriterier. Ikke desto mindre præsenteres de alle, på en eller anden måde, af udviklere som tilgængelige muligheder for installation af deres produkter. For at sammenfatte for de systemer, der er nævnt i den første del af artiklen, kan vi bemærke følgende metoder til deres implementering på en fysisk server eller virtuel maskine:
— brug af automatiserede installationsscripts eller manuel installation og efterfølgende konfiguration af den relevante software,
— brug af en færdig OS-image med forudinstalleret SMT-software og/eller agent,
— brug af containeriseringsteknologi (Docker).
De nævnte installationsmetoder har deres fordele og ulemper, og specialisterne har deres præferencer, begrænsninger og specifikke betingelser, hvorunder den infrastruktur, som de anvender eller implementerer, opererer, for at kunne fremsætte eventuelle anbefalinger. På den anden side er den givne beskrivelse af måderne til implementering af SIP-trafikovervågningssystemer ganske klar, og i øjeblikket kræver den ikke en mere detaljeret gennemgang.
Således blev endnu en artikel til, der er dedikeret til 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 dykke endnu dybere ned i detaljerne og se på produkterne HOMER SIP Capture og SIP3.
Kilde: habr.com
