Tere, kolleegid!
Uues eelnevas materjalis tutvustasime sellist kasulikku ja, nagu võib märgata, üsna vajalikku elementi VoIP-infrastruktuuris nagu liiklust jälgimise süsteem ehk LJS. Saime teada, mis see on, milliseid ülesandeid see täidab ning märkisime kõige silmapaistvamaid esindajaid, keda IT arendajad maailmale tutvustasid. Antud osas vaatleme põhimõtteid, mille kohaselt toimub LJS rakendamine IT-infrastruktuuris ja VoIP-liikluse jälgimine selle abil.
VoIP-liikluse jälgimise süsteemide arhitektuur
Me ehitasime, ehitasime ja lõpuks ehitasime valmis. Hurraa!
Multifilmist «Tšeburška ja krokodill Gena».
Nagu eelnevalt mainitud, on side- ja telekommunikatsioonitööstuses piisavalt tooteid, mis kuuluvad vastavasse kategooriasse. Siiski, kui abstraktseerida nime, arendaja, platvormi jne, siis võib märkida, et kõik need on rohkemasti sarnased oma arhitektuuri poolest (vähemalt need, millega autor on kokku puutunud). Tuleb märkida, et see on seotud eelkõige sellega, et puuduvad muud võimalused liikluse salvestamiseks võrgu elementidest selle järgmiseks detailseks analüüsiks. Seejuures, subjektiivselt öeldes, on see suuresti määratud erinevate valdkondade arengutega. Selgema arusaamise nimel vaatleme järgmisi analoogiaid.
Alates hetkest, kui suur vene teadlane Vladimir Aleksandrovitš Kotelnikov koostas mõõtureegli teooria, sai inimkond suurepärase võimaluse teostada analoog-digitaalset ja digitaal-analoogset muundumist häälsignaalides, tänu millele saame täielikult kasutada sellist imelist suhtlust nagu IP-telefonia. Kui vaadata hääl-signaalide töötlemismehhanismide (aka algoritmid, koodekid, kodeerimise meetodid jne) arengut, siis võib märgata, kuidas digitaalsed signaalitöötlused on teinud olulise sammu teabe edastamise kodeerimisel – hääl-signaali ennustamise võimaluse rakendamine. See tähendab, et lihtsalt digiteerimise ja a- ja u-kodeerimisseaduste (G.711A/G.711U) kasutamise asemel on nüüd võimalik edastada vaid osa mõõtudest, millest taastatakse kogu sõnum, säästes seeläbi oluliselt ribalaiust. Tagasi tulles SMT teema juurde, märkime, et praeguseks ei ole kvaliteedimuutusi liikluse haaramisel, välja arvatud erinevad peegeldamise variandid.
Vaatame edasi joonist, mis illustreerib, mida on vastava valdkonna spetsialistid ehitanud.
Joonis 1. SMT arhitektuuri üldskeem.
Peaaegu iga SMT koosneb kahest põhikomponendist: serverist ja liikluse haaramise agentidest (või proovidest). Server vastutab VoIP liikluse vastuvõtmise, töötlemise ja salvestamise eest, mis tuleb agentidelt, samuti annab spetsialistidele võimaluse töötada saadud teabega erinevates esitlustes (graafikud, diagrammid, Call Flow jne). Liikluse haaramise agendid teostavad VoIP liikluse vastuvõtmist võrgu tuumasüsteemi seadmetelt (nt SBC, softswitch, peab, jne), muundavad selle formaati, mida kasutatakse serveri tarkvaras, ja edastavad selle viimasele edasisteks manipuleerimiseks.
Nagu muusikas loovad heliloojad põhimeledest variatsioone, on ka antud juhul võimalik erinevaid rakendusvariante esitatud skeemile. Nende mitmekesisus on üsna suur ja peamiselt määrab selle infrastruktuuri omadused, milles SMT-d juurutatakse. Kõige sagedamini esinev variant on see, kus salvestusagente ei installita ega seadistata. Sellisel juhul suunatakse analüüsitud liiklus otse serveri või näiteks server saab vajaliku teabe pcapt-failidest, mille on koostanud jälgimisobjektid. Selline edastamisviis valitakse tavaliselt juhul, kui proovi paigaldamiseks ei ole võimalik. Varustuse paigalduskoha puudumine, virtuaalimise ressursipuudus, probleemid IP-transportvõrgu korraldamisega ja sellest tulenevad probleemid võrguühendusega jne, kõik need võivad olla põhjuseks valitud jälgimisorganisatsiooni variandi valimiseks.
Pärast aru saamist, kuidas erinev SMT saab IT-infrastruktuuri arhitektuuri seisukohalt rakendatud olla, vaatame nüüd aspekte, mis enamasti kuuluvad süsteemiadministraatorite pädevusse, nimelt tarkvara süsteemide paigaldamise viise serverites.
Jälgimisvõrgu antud komponendi rakendamise lahenduse ettevalmistamise käigus tekib täitjatel alati palju küsimusi. Näiteks, millised peaksid olema serveri riistvara koostisosad, kas kõigi süsteemi komponentide paigaldamine ühel hostil on piisav või tuleks need üksteisest eraldada, millisel viisil tarkvara paigaldada jne. Ülaltoodud ja paljusid teisi seotud küsimusi on väga ulatuslikud ning vastused paljudele neist sõltuvad tõesti konkreetsetest kasutustingimustest (või projekteerimisest). Kuid püüame üldistada konkreetset teavet, et saada üldine ülevaade ja arusaam sellest SMT-deploymendi küljest.
Nii, esimene küsimus, mis spetsialiste alati huvitab SMT rakendamisel, on see, milliste tehniliste omadustega serverit kasutada? Arvestades avatud lähtekoodiga tarkvara laialdast levikut, esitatakse see küsimus nii sageli, et selle populaarsust võib võrrelda küsimusega "Mida teha?", mille esitas veel Nikolai Gavrilovitš Tševõršev... Peamine tegur, mis mõjutab vastust, on meediasessioonide arv, mida telefoniplatvorm töötleb või hakkab töötlema. Numbriline ja tõeline omadus, mis annab konkreetse hinnangu mainitud tegurile, on parameeter CAPS (Call Attempts Per Second) või kõnede arv sekundis. K vajadus sellele küsimusele vastata tuleneb peamiselt sellest, et just teave sessioonide kohta, mis suunatakse süsteemi, loob koormuse selle serverile.
Teine küsimus, mis kerkib esile serveri riistvarakomponentide omaduste määramisel, on tarkvara koosseis (operatsioonikeskkonnad, andmebaasid jne), mis sellel töötama hakkab. Signaal- (või meedia) liiklus suunatakse serverisse, kus seda töödeldakse (signaalide sõnumite analüüs) mõne rakenduse (näiteks Kamailio) abil ning seejärel paigutatakse teatud viisil vormistatud teave andmebaasi. Erinevate SMT-de puhul võivad rakendused, mis teostavad signaalühikute defragmentatsiooni, ja rakendused, mis tagavad salvestamise, olla erinevad. Siiski, kõik need on seotud mitme protsessi loomuse tõttu. Samas, arvestades sellise infrastruktuuri elementi nagu SMT, tuleks selles punktis märkida, et diskile kirjutamise operatsioonide arv ületab oluliselt sealt lugemise operatsioonide 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 juurutamisel. Tsitaadi kõrvale toodud A.S. Puškini ajatu teosega seostatavad tehnoloogiad on laialdaselt levinud erinevates infrastruktuurides ja projektides. Ühest küljest on need omavahel tihedalt seotud, teisest küljest erinevad nad paljude kriteeriumide järgi silmapaistvalt. Sellegipoolest on kõik need, mingis vormis, arendajate poolt välja pakutud nende toodete installimise võimalustena. Kokkuvõtlikult on esimeses artikli osas loetletud süsteemide jaoks järgmised meetodid nende juurutamiseks füüsilisele serverile või virtuaalmasinale:
— automaatse installimise skriptide kasutamine või tarkvara käsitsi installimine ja sellele järgnevad seadistused,
— valmis OS pildi kasutamine, kus on eelnevalt installitud SMT tarkvara ja/või agent,
— konteineriseerimise tehnoloogia kasutamine (Docker).
Loetletud installimisvahenditel on oma eelised ja puudused, ja spetsialistidel on oma eelistused, piirangud ja konkreetsed tingimused, milles nad oma infrastrukturiga töötavad või rakendavad, et anda mingi soovitusi. Teisalt on antud SIP liikluse monitooringu süsteemide juurutamise teedes antud kirjeldus piisavalt selge ning praegusel etapil ei vaja see põhjalikumat uurimist.
Selline sai järjekordne artikkel, mis on pühendatud olulisele ja huvitavale elemendile VoIP-võrgus – SIP liikluse monitooringu süsteemile. Nagu ikka, tänan lugejaid antud materjali vastu huvi ülesnäitamise eest! Järgmisel osal püüame veel sügavamale minna ja uurida tooteid HOMER SIP Capture ja SIP3.
Allikas: habr.com
