Tere, kolleegid!
V materjalis tutvusime sellise kasuliku ja, nagu võib märkida, üsna vajaliku elemendiga VoIP-infrastruktuuris nagu liikluse jälgimise süsteem ehk lühidalt SMT. Uurisime, mis see on, milliseid ülesandeid see lahendab ning tõime esile silmapaistvamad esindajad, kes on IT-maailma tutvustanud. Käesolevas osas käsitleme põhimõtteid, mille kohaselt toimub SMT rakendamine IT-infrastruktuuris ja VoIP liikluse jälgimine selle abil.
VoIP-liikluse jälgimissüsteemide arhitektuur
Me ehitasime, ehitasime ja lõpuks ehitasime valmis. Hurra!
Multikast „Tšeburashka ja krokodill Gena“.
Nagu varem mainitud, on side- ja telekommunikatsioonitööstuses esindatud piisavalt tooteid, mis kuuluvad vastavasse kategooriasse. Siiski, kui jätta kõrvale nimi, arendaja, platvorm ja muud, on kõik nad arhitektuuri seisukohalt enam-vähem sarnased (vähemalt nendest, millega autor on kokku puutunud). Oluline on märkida, et see tuleneb just nimelt muudest meetodest, mis võimaldavad võrgu elementidelt andmete kogumist, et neid hiljem põhjalikult analüüsida. Subjektiivse arvamuse kohaselt määravad viimased pigem praegune erinevate valdkondade areng. Selgema arusaamise huvides vaatame järgmisi analoogiaid.
Alates hetkest, mil suur vene teadlane Vladimir Aleksandrovitš Kotelnikov lõi arvutusteoreemi, sai inimkond suurepärase võimaluse teostada analoogdigitaalset ja digitaalanaloogset konversiooni kõnesignaalidest, mille tõttu saame täielikult nautida nii imelist kommunikatsiooniviisi nagu IP-telefonia. Kui vaatame kõnesignaalide töötlemise mehhanismide arengut (st algoritmid, koodekid, kodeerimismeetodid jne), siis võime märgata, kuidas digitaalne signaalitöötlus (DST) on teinud põhimõttelise sammu teabe edastamise kodeerimises – kõnesignaali ennustamise võimaluse realiseerimises. See tähendab, et asemel, et lihtsalt digitaliseerida ja kasutada a- ja u-seaduse kokkusurumist (G.711A/G.711U), on nüüd võimalik edastada vaid osa andmepunktidest, mille põhjal taastatakse kogu sõnum, mis säästab oluliselt ribalaiust. Naastes SMT teema juurde, tasub märkida, et hetkel pole sarnaste kvaliteetsete muudatustega liiklustuvastamisviiside puhul peale mirrorimise ühtegi teist tõhusat varianti.
Vaadakem joonist, mis on toodud allpool ja illustreerib, mida on vastava valdkonna spetsialistid ehitanud.
Joonis 1. SMT üldine arhitektuuri skeem.
Peaaegu iga SMT koosneb kahest peamisest komponendist: serverist ja liiklushaardeagentidest (või proovivõtjatest). Server võtab, töötleb ja salvestab VoIP-iga seotud liiklust, mis pärineb agentidelt, ning võimaldab spetsialistidel töötada saadud teabega erinevates esitlustes (diagrammid, joonised, Call Flow jne). Liiklushaardeagentide ülesanne on võtta VoIP-liiklust võrgu tuumaseadmest (nt SBC, softswitch, väravad jne), muuta see serveri tarkvaras kasutatavasse formaati ning edastada see serverile edasisteks toiminguteks.
Nagu muusikas loovad heliloojad variaatioid peamistest meloodiatest, on ka antud juhul võimalikud erinevad variandid esitatud skeemi rakendamiseks. Nende mitmekesidus on piisavalt suur ja peamiselt määratletud infrastruktuuri omaduste järgi, kuhu SMT paigaldatakse. Kõige sagedamini esinev variant on see, kus mitte paigaldatakse ega seadistata grabimisagente. Sel juhul suunatakse analüüsitav liiklus otse serverile või näiteks saab server vajaliku teabe pcap-failidest, mille on moodustanud jälgimisobjektid. Sellist kohaletoimetamise viisi valitakse tavaliselt juhul, kui proovi seadistamine pole võimalik. Seadmestiku asukoha puudumine, virtualiseerimisvahendite ressursside nappus, transportiva IP-võrgu korraldamise vead ja seega probleemid võrguühendusega jne, kõik need võivad olla põhjuseks, miks valida märgitud monitorimise korraldusvarianti.
Mõistes, kuidas erinevad SMT-d saavad IT-infrastruktuuri arhitektuurilisest aspektist rakenduda, vaatleme nüüd aspekte, mis kuuluvad süsteemiadministraatorite pädevusse, nimelt tarkvarasüsteemide juurutamise viise serverites.
Lahenduse ettevalmistamise käigus võrgu jälgimise komponentide rakendamiseks tekib teostajatel alati palju küsimusi. Näiteks, milline peaks olema serveri riistvarakomplekt, kas kõik süsteemi komponendid peaksid olema ühel hostil või tasub need üksteisest eraldi paigutada, kuidas tarkvara installida jne. Ülaltoodud ja paljude teiste sarnaste küsimuste ulatus on suur ning palju vastuseid sõltuvad tõeliselt konkreetsetest kasutustingimustest (või projekteerimisest). Siiski püüame jagada spetsiifilisust, et saada üldine arusaam ja ülevaade SMT-de juurutamise sellest küljest.
Seega, esimene küsimus, mis alati huvitab spetsialiste SMT rakendamisel, on see, milliste tehniliste näitajatega serverit kasutada? Arvestades vabalt kergesti kättesaadava tarkvara laialdast levikut, küsitakse seda küsimust nii tihti, et selle populaarsuse tõttu võib-olla võiks seda võrrelda küsimusega "Mida teha?", mida küsis veel Nikolai Gavrilovitch Tšernishchev. Peamine tegur, mis mõjutab vastust, on meedia sessioonide arv, mida telefoni platvorm töötleb või hakkab töötlema. Kvantitatiivne ja mõõdetav karakteristik, mis annab konkreetse ülevaate nimetatud tegurist, on parameeter CAPS (Call Attempts Per Second) ehk kõnede arv sekundis. Selle küsimuse vastamise vajadus tuleneb eelkõige sellest, et just teave sessioonidest, mis suunatakse süsteemi, koormab selle serverit.
Teiseks küsimuseks, mis serveri riistvarakomponentide omaduste otsustamise käigus tekib, on tarkvara koostis (operatsioonikeskkonnad, andmebaasid jms), mis sellel töötama hakkab. Signaal- (või meedia) liiklus jõuab serverisse, kus seda töödeldakse (signaalisõnumite analüüsimine) mingi rakenduse (nt Kamailio) abil, pärast mida sorteeritud teave paigutatakse andmebaasi. Erinevate SMT-de jaoks võivad rakendused, mis teevad signaalüksuste defragmenteerimist, ning rakendused, mis pakuvad salvestamist, olla erinevad. Kuid kõiki neid ühendab ühte tüüpi mitme lõime tugi. Samas on oluline märkida, et selle infrastruktuuri elemendi, SMT, eripärast tulenevalt ületab kirjutamisoperatsioonide arv ketas arvukalt lugemisoperatsioonide arvu.
Ja lõpuks... "Kui palju on selles sõnas": server, virtualiseerimine, konteineriseerimine... Viimane, kuid väga oluline aspekt, mida selles artikli osas käsitletakse, on võimalikud viisid SMT komponentide installimiseks selle kasutusele võtmisel. Tehnoloogiad, mis on loetletud A.S. Pusjkini surematu teose tsitaadi kõrval, on laialdaselt levinud erinevates infrastruktuurides ja projektides. Ühest küljest on nad tihedalt omavahel seotud, kuid teisest küljest erinevad nad paljuski. Siiski on kõik need, ühel või teisel kujul, välja töötajad esitanud kui saadavalolevaid variante oma toodete installimiseks. Kokkuvõtteks loetletud süsteemide jaoks, mida käsitleti artikli esimeses osas, tuletame meelde järgmisi viise nende juurutamiseks füüsilisele serverile või virtuaalsele masinale:
— automaatse installimise skriptide kasutamine või käsitsi installimine ja vastava tarkvara hilisem seadistamine,
— valmis OS-pildi kasutamine, milles on eelinstallitud SMT ja/või agendi tarkvara,
— konteineriseerimise tehnoloogia kasutamine (Docker).
Loetletud installimisvahenditel on oma eelised ja puudused ning spetsialistidel on omad eelistused, piirangud ja konkreetsed tingimused, milles nad kasutavad või rakendavad oma infrastruktuuri, et anda soovitusi. Teisest küljest on antud SIP-traffiku jälgimise süsteemide juurutamise kirjeldus piisavalt selge ja sellel hetkel ei vaja see detailsemat käsitlemist.
See on veel üks artikkel, mis on pühendatud VoIP-võrgu olulisele ja huvitavale elemendile – SIP-traffiku jälgimise süsteemile. Nagu alati, tänan lugejaid selle materjali vastu näidatud huvi eest! Järgmises osas püüame veelgi sügavamale minna ja käsitleda tooteid HOMER SIP Capture ja SIP3.
Allikas: habr.com
