Övervakningssystem för trafik i VoIP-nätverk. Del två — principer för organisation

Hej kollegor!

I föregående I det tidigare materialet bekantade vi oss med en så användbar och, som man kan se, ganska nödvändig del av VoIP-infrastrukturen som trafikövervakningssystemet, eller kort sagt, TOM. Vi lärde oss vad det är, vilka uppgifter det löser och nämnde också de mest framträdande representanterna som utvecklarna har presenterat för IT-världen. I det här avsnittet kommer vi att titta på de principer som ligger till grund för implementeringen av TOM i IT-infrastrukturen och övervakningen av VoIP-trafik med hjälp av den.

Arkitektur för VoIP-trafikövervakningssystem

Vi byggde, byggde och till slut byggde vi. Hurra!
Från tecknad filmen 'Tjeburashka och krokodilen Gena'.

Som tidigare noterats finns det ett antal produkter inom kommunikation och telekommunikation som tillhör den aktuella kategorin. Men om vi abstraherar från namnet, utvecklaren, plattformen och så vidare, kan vi se att de alla mer eller mindre är lika när det gäller sina arkitekturer (åtminstone de som författaren har stött på). Det är värt att notera att detta är kopplat till det faktiska frånvaron av några andra metoder för att fånga trafik från nätverkskomponenter för att analysera den i detalj. Denna punkt, enligt subjektiv åsikt, är mer eller mindre definierad av den aktuella utvecklingen inom olika områden av branschen. För en tydligare förståelse, låt oss överväga följande analogi.

Sedan den stora ryska forskaren Vladimir Alexandrovich Kotelnikov skapade referenssatsen, fick mänskligheten en enorm möjlighet att utföra analog-till-digital och digital-till-analog konvertering av talande signaler, vilket gör att vi fullt ut kan använda den fantastiska kommunikationsmetoden IP-telefoni. Om vi ser på utvecklingen av signalbehandlingsmekanismer (även kända som algoritmer, codec, kodningsmetoder etc.), kan vi märka hur DSP (digital signalbehandling) gjorde ett avgörande steg i kodningen av informationsmeddelanden – att implementera möjligheten att förutsäga tal-signalen. Det vill säga, istället för enbart digitization och användning av a- och u-kompressionslagar (G.711A/G.711U), finns det nu möjlighet att överföra endast en del av avläsningarna med efterföljande återställande av hela meddelandet, vilket väsentligt sparar bandbredd. Återgå till ämnet SMT, notera att det för närvarande inte finns några liknande kvalitetsändringar i tillvägagångssättet för att fånga trafik, förutom olika typer av spegling.

Låt oss titta på bilden som presenteras nedan och som illustrerar vad som har byggts av specialister inom de relevanta ämnesområdena.

Figur 1. Allmän skiss av SMT-arkitekturen.

Nästan varje SMT består av två huvudkomponenter: en server och trafikfångstagare (eller provtagare). Servern tar emot, bearbetar och lagrar VoIP-trafik som kommer från agenter, samt ger specialisterna möjlighet att arbeta med den mottagna informationen i olika former (grafer, diagram, Call Flow, etc.). Trafikfångst-agenterna tar emot VoIP-trafik från nätverkets kärnutsättningar (till exempel SBC, softswitch, gateways, ...), omvandlar den till det format som används i den programvara som servern i systemet använder, och överför den till den sista för vidare manipulering.

Precis som kompositörer skapar variationer på huvudmelodier i musiken, finns det i detta fall olika sätt att implementera den angivna schemat. Mångfalden är ganska stor och bestäms främst av egenskaperna hos infrastrukturen där SMT:en implementeras. Den mest förekommande varianten är den där avlyssningsagenter inte installeras eller konfigureras. I detta fall dirigeras den analyserade trafiken direkt till servern eller, till exempel, så får servern nödvändig information från pcap-filer som har skapats av övervakningsobjekten. Denna leveransmetod väljs i allmänhet när det inte finns möjlighet att installera provare. Platsen för utrustningens installation, brist på resurser för virtualisering, brister i organisationen av den transportabla IP-nätverket och som en följd av detta problem med nätverksanslutningen etc., kan allt detta vara orsaken till valet av den nämnda övervakningsorganisationsvarianten.

När vi har lärt oss och förstått hur en viss SMT kan implementeras i IT-infrastrukturen ur ett arkitektoniskt perspektiv, går vi vidare till aspekter som mer faller inom systemadministratörernas kompetens, nämligen sätt att distribuera programvarusystem på servrar.

Under förberedelserna av lösningen för att genomföra den aktuella komponenten i övervakningsnätverket uppstår det alltid många frågor för utförarna. Till exempel, vad bör sammansättningen av serverns hårdvara vara, är det tillräckligt att installera alla systemkomponenter på en och samma värd, eller ska de separeras från varandra, hur ska programvaran installeras, etc. De ovannämnda samt många andra relaterade frågor är mycket omfattande, och svaren på många av dem beror faktiskt på specifika drifts- eller konstruktionsvillkor. Men vi ska försöka sammanfatta det specifika för att få en allmän bild och förståelse av denna aspekt av SMT-deployeringen.

Först och främst är det alltid en fråga som intresserar specialister när man implementerar en CPX – vilken hårdvaruspecifikation som ska användas för servern? Med tanke på den utbredda användningen av fri programvara ställs denna fråga så många gånger att dess popularitet antagligen kan jämföras med frågan "Vad ska man göra?", ställd av Nikolaj Gavrilovitj Tjernysjevskij… Den viktigaste faktorn som påverkar svaret är antalet mediesessioner som plattformen för telefonitjänster bearbetar eller kommer att bearbeta. Det numeriska och konkreta måttet som ger en specifik bedömning av denna faktor är CAPS-parametern (Call Attempts Per Second) eller antal samtal per sekund. Behovet av att svara på denna fråga är först och främst kopplat till den information om sessionerna som skickas till systemet och som kommer att skapa belastning på dess server.

Den andra frågan som uppstår vid beslut om specifikationerna för serverns hårdvarukomponenter är sammansättningen av programvaran (operativsystem, databaser etc.) som kommer att fungera på den. Signalerings- (eller medietrafik) strömmar till servern, där den bearbetas (analys av signalmeddelanden) av en viss applikation (till exempel Kamailio), och den information som på ett visst sätt har formats placeras i databasen. För olika CPX, både applikationer som utför defragmentering av signalenheter och applikationer som tillhandahåller lagring, kan vara olika. Men alla förenas av den gemensamma egenskapen av multitrådning. Vidare, på grund av de specifika egenskaperna hos ett element i infrastrukturen som CPX, bör det noteras att antalet skrivoperationer till disk överstiger antalet läsoperationer från den.

Och till sist... "Hur mycket finns det i detta ord": server, virtualisering, containerisering... Den sista men mycket viktiga aspekten som tas upp i denna del av artikeln handlar om möjliga sätt att installera komponenterna i SMT vid dess implementering. De teknologier som nämns intill citatet från A.S. Pushkins odödliga verk är allmänt förekommande i olika infrastrukturer och projekt. Å ena sidan är de nära kopplade till varandra, å andra sidan skiljer de sig markant åt på många kriterier. Ändå är de alla, i en eller annan form, representerade av utvecklare som tillgängliga alternativ för installation av sina produkter. Om vi sammanfattar de system som nämndes i den första delen av artikeln kan vi notera följande sätt att implementera dem på en fysisk server eller virtuell maskin:
— användning av automatiska installationsskript eller manuell installation och efterföljande konfiguration av relevant programvara,
— användning av en färdig OS-avbild med förinstallerad SMT-programvara och/eller agent,
— användning av containeriseringsteknik (Docker).

De nämnda installationsmetoderna har sina fördelar och nackdelar, och specialister har sina preferenser, begränsningar och specifika villkor i vilka den utnyttjade eller implementerade infrastrukturen befinner sig, för att kunna ge några rekommendationer. Å andra sidan är den beskrivna vägen för implementering av SIP-trafikövervakningssystem tillräckligt transparent, och i detta skede kräver det ingen mer detaljerad granskning.

Så blev det ännu en artikel, dedikerad till en viktig och intressant del av VoIP-nätverket – SIP-trafikövervakningssystemet. Som alltid tackar jag läsarna för deras intresse för detta material! I nästa del kommer vi att försöka fördjupa oss ännu mer i specifikationerna och granska produkterna HOMER SIP Capture och SIP3.

Källa: habr.com