Hei kollegat!
В Materiaalissa tutustuimme sellaiseen hyödylliseen ja, kuten näette, varsin tarpeelliseen VoIP-infrastruktuurin elementtiin, kuten liikenteenvalvontajärjestelmään tai lyhyesti sanottuna SMT:hen. Selvitimme, mikä se on, mitä ongelmia se ratkaisee, ja huomasimme myös kehittäjien IT-maailmalle esittämät näkyvimmät edustajat. Tässä osiossa tarkastellaan periaatteita, joiden mukaan SMT toteutetaan IT-infrastruktuurissa ja VoIP-liikenteen seurantaa sen keinoin toteutetaan.
VoIP-liikenteen valvontajärjestelmien arkkitehtuuri
Rakensimme ja rakensimme ja lopulta rakensimme. Hurraa!
Sarjakuvasta "Cheburashka ja krokotiili Gena".
Kuten aiemmin todettiin, viestintä- ja telealalla on riittävästi vastaavaan kategoriaan kuuluvia tuotteita. Kuitenkin, jos otamme abstraktin nimestä, kehittäjästä, alustasta jne., voimme nähdä, että ne ovat kaikki enemmän tai vähemmän samanlaisia arkkitehtuuriltaan (ainakin ne, joita kirjoittaja joutui käsittelemään). On syytä huomata, että tämä johtuu nimenomaan muiden menetelmien puuttumisesta liikenteen sieppaamiseksi verkkoelementeistä sen myöhempää yksityiskohtaista analyysiä varten. Lisäksi jälkimmäinen määräytyy subjektiivisen mielipiteen mukaan suurelta osin aiheteollisuuden eri alojen nykyisestä kehityksestä. Selvemmän käsityksen saamiseksi harkitse seuraavaa analogiaa.
Siitä hetkestä lähtien, kun suuri venäläinen tiedemies Vladimir Aleksandrovich Kotelnikov loi näytteenottolauseen, ihmiskunta on saanut valtavan mahdollisuuden suorittaa puhesignaalien analogia-digitaali- ja digitaali-analogimuunnoksia, minkä ansiosta voimme täysin käyttää tällaista upeaa tyyppiä. viestintä IP-puhelimena. Jos tarkastellaan puhesignaalien käsittelymekanismien (alias algoritmit, koodekit, koodausmenetelmät jne.) kehitystä, voit nähdä, kuinka DSP (digitaalinen signaalinkäsittely) on ottanut perustavanlaatuisen askeleen informaatioviestien koodauksessa - toteuttanut kyvyn ennustaa. puhesignaali. Toisin sanoen pelkän digitoinnin ja a- ja u-pakkauslakien (G.711A/G.711U) käyttämisen sijaan on nyt mahdollista lähettää vain osa näytteistä ja sitten palauttaa niistä koko viesti, mikä säästää merkittävästi kaistanleveys. Palataksemme MMT-aiheeseen, toteamme, että tällä hetkellä liikenteen kaappauksen lähestymistavassa ei ole samanlaisia laadullisia muutoksia kuin yhden tai toisen tyyppinen peilaus.
Siirrytään alla olevaan kuvaan, joka havainnollistaa, mitä asianomaisten aihealueiden asiantuntijat ovat rakentaneet.
Kuva 1. SMT-arkkitehtuurin yleinen kaavio.
Melkein mikä tahansa SMT koostuu kahdesta pääkomponentista: palvelimesta ja liikenteen sieppausagenteista (tai antureista). Palvelin vastaanottaa, käsittelee ja tallentaa VoIP-liikennettä, joka tulee agenteilta, ja tarjoaa myös asiantuntijoille mahdollisuuden käsitellä vastaanotettuja tietoja eri näkymissä (kaaviot, kaaviot, puhelunkulku jne.). Sieppausagentit vastaanottavat VoIP-liikennettä verkon ydinlaitteilta (esim. SBC, softswitch, yhdyskäytävät jne.), muuntaa sen sovelletussa järjestelmäpalvelinohjelmistossa käytettyyn muotoon ja siirtää sen jälkimmäiseen myöhempää käsittelyä varten.
Aivan kuten musiikissa, säveltäjät luovat variaatioita teosten päämelodioihin, joten tässä tapauksessa erilaiset vaihtoehdot yllä olevan järjestelmän toteuttamiseksi ovat mahdollisia. Niiden monimuotoisuus on melko suuri, ja sen määräävät pääasiassa sen infrastruktuurin ominaisuudet, jossa MMT on käytössä. Yleisin vaihtoehto on sellainen, jossa sieppausagentteja ei ole asennettu tai määritetty. Tällöin analysoitu liikenne lähetetään suoraan palvelimelle tai esimerkiksi palvelin saa tarvittavat tiedot valvontaobjektien luomista pcap-tiedostoista. Tämä toimitustapa valitaan yleensä, jos antureita ei ole mahdollista asentaa. Laitteen sijainti sivustolla, resurssien puute virtualisointityökaluille, puutteita liikenteen IP-verkon organisoinnissa ja sen seurauksena verkkoyhteyksien ongelmat jne., kaikki tämä voi olla syynä mainitun valinnan tekemiseen. mahdollisuus valvonnan järjestämiseen.
Oppittuamme ja ymmärtäen, miten tämä tai toinen SMT voidaan toteuttaa IT-infrastruktuuriin arkkitehtonisesta näkökulmasta, tarkastelemme seuraavaksi asioita, jotka kuuluvat enemmän järjestelmänvalvojien toimivaltaan, nimittäin menetelmiä järjestelmäohjelmistojen käyttöönottamiseksi palvelimilla.
Käsiteltävänä olevan valvontaverkkokomponentin käyttöönottopäätöstä valmisteltaessa toteuttajilla on aina monia kysymyksiä. Esimerkiksi millainen pitäisi olla palvelinlaitteiston koostumus, riittääkö kaikkien järjestelmäkomponenttien asentaminen yhdelle isännälle vai pitäisikö ne erottaa toisistaan, miten ohjelmisto asennetaan jne. Yllä luetellut kysymykset, kuten myös monet muut asiaan liittyvät kysymykset, ovat hyvin laajoja, ja vastaukset moniin niistä riippuvat todella käyttöolosuhteista (tai suunnittelusta). Yritämme kuitenkin tehdä yhteenvedon yksityiskohdista saadaksemme yleiskuvan ja käsityksen CMT:n käyttöönoton tältä puolelta.
Joten ensimmäinen asia, josta asiantuntijat ovat aina kiinnostuneita SMT:tä toteutettaessa, on, millä suorituskykyominaisuuksilla palvelinta tulisi käyttää? Kun otetaan huomioon vapaiden ohjelmistojen laaja käyttö, tämä kysymys esitetään niin monta kertaa, että sen suosiota voi luultavasti verrata Nikolai Gavrilovich Chernyshevskyn esittämään kysymykseen "Mitä minun pitäisi tehdä?"... Vastaamiseen vaikuttaa eniten ohjelmien määrä. mediaistunnot, jotka puhelinympäristö käsittelee tai käsittelee. Numeerinen ja konkreettinen ominaisuus, joka antaa erityisen arvion havaitusta tekijästä, on CAPS (Call Attempts Per Second) -parametri tai puheluiden määrä sekunnissa. Tarve vastata tähän kysymykseen johtuu ensisijaisesti siitä, että tieto järjestelmään lähetetyistä istunnoista kuormittaa sen palvelinta.
Toinen ongelma, joka nousee esiin päätettäessä palvelimen laitteistokomponenttien ominaisuuksista, on siinä toimivan ohjelmiston (käyttöympäristöt, tietokannat jne.) koostumus. Signaali- (tai media-) liikenne saapuu palvelimelle, jossa jokin sovellus (esim. Kamailio) käsittelee sen (signaaliviestit jäsentävät) ja sitten tietyllä tavalla tuotettu tieto sijoitetaan tietokantaan. Eri CMT:issä sekä signaaliyksiköitä eheyttävät sovellukset että tallennustilaa tarjoavat sovellukset voivat olla erilaisia. Niitä kaikkia yhdistää kuitenkin sama monisäikeyden luonne. Samaan aikaan tällaisen infrastruktuurielementin, kuten SMT, erityispiirteistä johtuen on tässä vaiheessa huomattava, että levylle tehtävien kirjoitustoimintojen määrä ylittää merkittävästi siltä lukutoimintojen määrän.
Ja lopuksi... "Tässä sanassa on niin paljon": palvelin, virtualisointi, kontti... Viimeinen, mutta erittäin tärkeä näkökohta, jota tässä artikkelin osassa käsitellään, ovat mahdolliset tavat asentaa MMT-komponentteja sen käyttöönoton aikana. Listattu lainauksen viereen A.S.:n kuolemattomasta teoksesta. Pushkin-teknologiaa käytetään laajasti erilaisissa infrastruktuureissa ja projekteissa. Toisaalta ne liittyvät läheisesti toisiinsa, ja toisaalta ne eroavat silmiinpistävästi monissa kriteereissä. Kehittäjät kuitenkin esittävät ne kaikki muodossa tai toisessa käytettävissä olevina vaihtoehtoina tuotteidensa asentamiseen. Yhteenvetona artikkelin ensimmäisessä osassa luetelluista järjestelmistä huomaamme seuraavat menetelmät niiden käyttöönottamiseksi fyysisessä palvelimessa tai virtuaalikoneessa:
— automaattisten asennuskomentosarjojen käyttö tai vastaavan ohjelmiston itseasennus ja myöhempi konfigurointi,
— valmiin käyttöjärjestelmäkuvan käyttö esiasennetun SMT-ohjelmiston ja/tai agentin kanssa,
— konttiteknologian käyttö (Docker).
Luetteloiduilla asennustyökaluilla on hyvät ja huonot puolensa, ja asiantuntijoilla on omat mieltymyksensä, rajoituksensa ja erityisolosuhteet, joissa heidän käyttämänsä tai toteuttamansa infrastruktuuri sijaitsee, jotta he voivat esittää suosituksia. Toisaalta annettu kuvaus SIP-liikenteen seurantajärjestelmien käyttöönottotavoista on varsin läpinäkyvä, eikä vaadi tässä vaiheessa tarkempaa pohdintaa.
Tämä on toinen artikkeli, joka on omistettu tärkeälle ja mielenkiintoiselle VoIP-verkon elementille - SIP-liikenteen seurantajärjestelmälle. Kuten aina, kiitän lukijoita huomiosta tähän materiaaliin! Seuraavassa osassa yritämme mennä vielä syvemmälle yksityiskohtiin ja tarkastella HOMER SIP Capture- ja SIP3-tuotteita.
Lähde: will.com