Tere kolleegid!
В Materjalis tutvusime sellise kasuliku ja, nagu näha, üsna vajaliku VoIP infrastruktuuri elemendiga nagu liiklusseiresüsteem ehk lühidalt SMT. Saime teada, mis see on, milliseid probleeme see lahendab, ning märkisime ära ka silmapaistvamad esindajad, mida arendajad IT-maailmale esitlesid. Selles osas käsitleme põhimõtteid, mille järgi SMT IT-taristusse juurutatakse ja selle vahendeid kasutades VoIP liikluse monitooringut teostatakse.
VoIP liiklusseiresüsteemide arhitektuur
Ehitasime ja ehitasime ja lõpuks ehitasime. Hurraa!
Multifilmist "Tšeburaška ja krokodill Gena".
Nagu varem märgitud, on side- ja telekommunikatsioonitööstuses piisavalt tooteid, mis kuuluvad vastavasse kategooriasse. Kui aga abstraheerida nimest, arendajast, platvormist vms, siis näeme, et need on kõik oma arhitektuuri poolest enam-vähem samad (vähemalt need, millega autor pidi tegelema). Väärib märkimist, et see on tingitud just muude meetodite puudumisest võrguelementide liikluse hõivamiseks selle hilisemaks üksikasjalikuks analüüsiks. Pealegi määrab viimase subjektiivsel arvamusel suuresti teematööstuse erinevate valdkondade praegune areng. Selgema arusaamise jaoks kaaluge järgmist analoogiat.
Alates hetkest, kui suur vene teadlane Vladimir Aleksandrovitš Kotelnikov lõi diskreetiteoreemi, on inimkond saanud tohutu võimaluse kõnesignaalide analoog-digitaal- ja digitaal-analoogmuundamiseks, tänu millele saame seda imelist tüüpi täielikult kasutada. side kui IP-telefon. Kui vaadata kõnesignaalide töötlemise mehhanismide (ehk algoritmid, koodekid, kodeerimismeetodid jne) arengut, siis on näha, kuidas DSP (digitaalne signaalitöötlus) on astunud põhimõttelise sammu infosõnumite kodeerimisel – rakendades ennustamisvõimet. kõnesignaal. See tähendab, et selle asemel, et lihtsalt digitaliseerida ja kasutada tihendusseadusi a- ja u-tüüpi (G.711A/G.711U), on nüüd võimalik edastada ainult osa näidistest ja seejärel taastada nendest kogu sõnum, mis säästab oluliselt ribalaius. Tulles tagasi MMT teema juurde, märgime, et hetkel ei ole liiklushõive käsitluses sarnaseid kvalitatiivseid muutusi peale ühe või teise peegeldamise tüübi.
Pöördume alloleva joonise juurde, mis illustreerib asjakohaste valdkondade spetsialistide poolt ehitatut.
Joonis 1. SMT arhitektuuri üldskeem.
Peaaegu iga SMT koosneb kahest põhikomponendist: serverist ja liikluse hõivamise agentidest (või sondidest). Server võtab vastu, töötleb ja salvestab agentidelt tulevat VoIP-liiklust ning annab spetsialistidele ka võimaluse töötada saadud teabega erinevates vaadetes (graafikud, diagrammid, kõnevoog jne). Capture agendid võtavad vastu VoIP-liiklust võrgu põhiseadmetelt (näiteks SBC, softswitch, lüüsid jne), teisendavad selle rakendatud süsteemiserveri tarkvaras kasutatavasse vormingusse ja edastavad selle hilisemaks manipuleerimiseks.
Nii nagu muusikas, loovad heliloojad variatsioone teoste põhimeloodiatele, nii on ka sel juhul ülaltoodud skeemi rakendamiseks võimalikud erinevad variandid. Nende mitmekesisus on üsna suur ja selle määravad peamiselt MMT-d kasutava infrastruktuuri omadused. Kõige tavalisem valik on selline, mille puhul pole installitud ega konfigureeritud ühtegi püüdmisagenti. Sel juhul saadetakse analüüsitud liiklus otse serverisse või näiteks saab server vajaliku info seireobjektide poolt genereeritud pcap-failidest. See tarneviis valitakse tavaliselt siis, kui sonde pole võimalik paigaldada. Seadmete asukoht saidil, ressursside puudumine virtualiseerimistööriistade jaoks, vead transpordi IP-võrgu korralduses ja sellest tulenevalt võrguühenduse probleemid jne, kõik see võib olla märgitud märgitud valiku põhjuseks. seire korraldamise võimalus.
Olles õppinud ja mõistnud, kuidas seda või teist SMT-d saab arhitektuurilisest aspektist IT-taristusse juurutada, võtame järgmisena vaatluse alla aspektid, mis on pigem süsteemiadministraatorite pädevuses, nimelt süsteemitarkvara serverites juurutamise meetodid.
Vaadeldava seirevõrgu komponendi rakendamise otsuse ettevalmistamisel tekib rakendajatel alati palju küsimusi. Näiteks milline peaks olema serveri riistvara koostis, kas piisab kõigi süsteemikomponentide installimisest ühte hosti või tuleks need üksteisest eraldada, kuidas installida tarkvara jne. Eespool loetletud küsimused, nagu ka paljud teised sellega seotud küsimused, on väga laiaulatuslikud ja paljudele neist sõltuvad vastused tõesti konkreetsetest töötingimustest (või disainist). Püüame siiski üksikasjad kokku võtta, et saada üldine ettekujutus ja arusaam sellest CMT kasutuselevõtu aspektist.
Niisiis, esimene asi, millest spetsialistid SMT juurutamisel alati huvi pakuvad, on see, milliste jõudlusnäitajatega tuleks serverit kasutada? Arvestades vabatarkvara laialdast kasutamist, esitatakse seda küsimust nii palju kordi, et selle populaarsust võib ilmselt võrrelda Nikolai Gavrilovitš Tšernõševski küsimusega “Mida ma peaksin tegema?”... Peamine vastust mõjutav tegur on meediaseansid, mida töötleb või hakkab töötlema telefoniplatvorm. Numbriline ja käegakatsutav tunnus, mis annab konkreetse hinnangu märgitud tegurile, on CAPS (Call Attempts Per Second) parameeter ehk kõnede arv sekundis. Sellele küsimusele vastamise vajadus tuleneb eelkõige sellest, et selle serverit koormab just info süsteemile saadetud seansside kohta.
Teine probleem, mis serveri riistvarakomponentide omaduste üle otsustamisel tekib, on sellel töötava tarkvara (töökeskkonnad, andmebaasid jne) koostis. Signaali (või meediumi) liiklus jõuab serverisse, kus seda töötleb (signaalisõnumeid sõelub) mõni rakendus (näiteks Kamailio) ning seejärel paigutatakse teatud viisil genereeritud info andmebaasi. Erinevate CMT-de puhul võivad nii signaaliüksusi defragmenteerivad kui ka salvestusruumi pakkuvad rakendused olla erinevad. Neid kõiki ühendab aga sama mitmelõimelisuse olemus. Samal ajal tuleb sellise infrastruktuurielemendi nagu SMT iseärasuste tõttu siinkohal märkida, et kettale kirjutamistoimingute arv ületab oluliselt sellelt lugemisoperatsioonide arvu.
Ja lõpuks... "Selles sõnas on nii palju": server, virtualiseerimine, konteineriseerimine... Viimane, kuid väga oluline aspekt, mida selles artiklis puudutatakse, on võimalikud viisid MMT komponentide installimiseks selle juurutamise ajal. Loetletud tsitaadi kõrval A.S. surematust teosest. Puškini tehnoloogiaid kasutatakse laialdaselt erinevates infrastruktuurides ja projektides. Ühest küljest on need üksteisega tihedalt seotud ja teisest küljest erinevad nad paljude kriteeriumide poolest silmatorkavalt. Kuid arendajad esitavad neid kõiki ühel või teisel kujul oma toodete installimiseks saadaolevate valikutena. Artikli esimeses osas loetletud süsteemide kokkuvõtteks märgime järgmisi meetodeid nende juurutamiseks füüsilises serveris või virtuaalses masinas:
— automaatsete installiskriptide kasutamine või vastava tarkvara iseinstallimine ja sellele järgnev konfigureerimine,
— valmis OS-i kujutise kasutamine koos eelinstallitud SMT-tarkvara ja/või agendiga,
— konteineriseerimistehnoloogia kasutamine (Docker).
Loetletud paigaldustööriistadel on oma eelised ja puudused ning spetsialistidel on soovituste esitamiseks oma eelistused, piirangud ja konkreetsed tingimused, milles nende käitatav või rakendatav infrastruktuur asub. Teisest küljest on antud SIP-liikluse jälgimise süsteemide juurutamise viiside kirjeldus üsna läbipaistev ega vaja praeguses staadiumis põhjalikumat käsitlemist.
See on veel üks artikkel, mis on pühendatud VoIP-võrgu olulisele ja huvitavale elemendile - SIP-liikluse jälgimissüsteemile. Nagu alati, tänan lugejaid tähelepanu eest sellele materjalile! Järgmises osas proovime minna veelgi sügavamale spetsiifikasse ja vaadata HOMER SIP Capture ja SIP3 tooteid.
Allikas: www.habr.com