Üdvözlöm, kollégák!
A A cikkben megismerkedtünk egy hasznos, és mint látható, elég szükséges elemmel az VoIP infrastruktúrában, amely nem más, mint a forgalomfigyelő rendszer, vagy röviden SFT. Megtudtuk, hogy mi az, milyen feladatokat lát el, és említettük a legkiemelkedőbb képviselőket, akiket a fejlesztők bemutattak az IT világának. Ebben a részben a SFT IT infrastruktúrába való integrálásának és a VoIP forgalom megfigyelésének elveit fogjuk megvizsgálni.
VoIP-forgalom figyelőrendszerének architektúrája
Építettük, építettük, és végre megépítettük. Hurrá!
A „Csibész és Gena, a krokodil” című meséből.
Mint korábban említve lett, a kommunikációs és telekommunikációs iparágban számos olyan termék található, amelyek a megfelelő kategóriába tartoznak. Azonban, ha eltekintünk a névtől, a fejlesztőtől, a platformtól, és egyebektől, akkor észrevehetjük, hogy mindezek többé-kevésbé hasonlóak az architektúrájuk szempontjából (legalábbis azok, amelyekkel az író találkozott). Érdemes megjegyezni, hogy ez pontosan annak a következménye, hogy egyszerűen hiányoznak más módszerek a forgalom begyűjtésére a hálózati elemekről a további részletes elemzéshez. Ezen utóbbi szubjektív véleményem szerint nagyobb mértékben függ a megfelelő iparág különböző területeinek jelenlegi fejlesztésétől. Az egyértelműbb megértés érdekében vizsgáljuk meg a következő analógiát.
Attól a pillanattól kezdve, hogy a nagy orosz tudós, Vladimir Alexandrovich Kotelnikov megalkotta az összehasonlítási tételt, az emberiség hatalmas lehetőséget kapott analóg-digitális és digitális-analóg beszédjelek átalakítására, amelynek köszönhetően teljes mértékben kihasználhatjuk az IP-telefonálás csodálatos formáját. Ha megnézzük a beszédjelek feldolgozásának mechanizmusait (azaz algoritmusok, kodekek, kódolási módszerek stb.), észrevehetjük, hogy a digitális jelek feldolgozása lényeges lépést tett az információs üzenetek kódolásában – a beszédjel előrejelzési lehetőségének megvalósítását. Tehát ahelyett, hogy egyszerűen digitalizálnánk és a kompressziós törvények (G.711A/G.711U) használatát alkalmaznánk, most lehetőség van csupán a minták egy részének továbbítására, amelyből később az egész üzenet visszaállítható, ami jelentősen megtakarítja a sávszélességet. Visszatérve a SMT témájára, megjegyzendő, hogy jelenleg nincsenek hasonló minőségi változások a forgalom rögzítésének megközelítésében, más alternatív módszerek mellett.
Tekintsük meg az alábbi ábrát, amely illusztrálja, hogy mi épült a megfelelő szakmai területek szakértői által.
1. ábra. Az SMT architektúrájának általános séma.
Gyakorlatilag bármely SMT két fő összetevőből áll: szerverből és forgalom figyelő ügynökökből (vagy mintákból). A szerver fogadja, feldolgozza és tárolja a VoIP-forgalmat, amely az ügynököktől érkezik, valamint lehetőséget biztosít a szakértők számára az információval való munkára különböző formákban (grafikonok, diagramok, Call Flow stb.). A forgalom figyelő ügynökök a VoIP-forgalmat fogadják a hálózat magjának berendezéseitől (például SBC, softswitch, átjárók stb.), átalakítják azt a rendszer szerverének szoftveréhez használt formátumra, és továbbítják a szervernek a további manipulációkhoz.
Ahogyan a zenében a zeneszerzők variációkat készítenek a művek főmelódiáira, úgy ebben az esetben is különböző megvalósítási lehetőségek állnak rendelkezésre a megadott rendszerhez. Ezek sokfélesége meglehetősen széles, és főként az infrastruktúra jellemzői határozzák meg, amelyben a SMT telepítve van. A leggyakrabban előforduló variáció az, amikor nem telepítenek és nem állítanak be felügyeleti ügynököket. Ebben az esetben az elemzett forgalom közvetlenül a szerverhez vagy például a szerver a szükséges információkat a monitoring által generált pcap fájlokból nyeri ki. Ez a szállítási mód általában akkor van választva, ha nincs lehetőség probákat telepíteni. Az eszköz elhelyezésére szolgáló hely, a virtualizációs források hiánya, a szállító IP-hálózat szervezésének hiányosságai, és mint következmény, a hálózati kapcsolódás problémái stb. mind okai lehetnek ennek a monitorozási lehetőségnek a választásának.
Miután megértettük és átvettük, hogyan lehet egy adott SMT-t az IT-infrastruktúrába integrálni architekturális szempontból, a következőkben a rendszergazdák hatáskörébe tartozó szempontokat vizsgáljuk meg, nevezetesen a rendszerprogramok szervereken történő telepítésének módjait.
A monitoring hálózat megvalósítására vonatkozó megoldás előkészítése során a végrehajtók mindig számos kérdéssel találkoznak. Például, milyen legyen a szerver hardverének összeállítása, elegendő-e az összes rendszerkomponens telepítése egyetlen hoszton, vagy érdemes-e azokat különválasztani, miként végezzük a szoftver telepítését stb. A fent említettek, és még sok más kapcsolódó kérdés kiterjedt, és sokukra a válaszok valóban a munkakörülmények (vagy tervezés) sajátosságaitól függenek. Ennek ellenére próbáljuk összefoglalni a konkrétumokat, hogy általános képet és megértést kapjunk a SMT telepítésének e vonatkozásáról.
Tehát az első kérdés, ami mindig foglalkoztatja a szakembereket a SMT megvalósítása során, az az, hogy mely technikai paraméterekkel használják a szervert? Figyelembe véve a nyílt forráskódú szoftverek széleskörű elterjedését, ezt a kérdést annyiszor teszik fel, hogy népszerűsége talán összehasonlítható Nikolaj Gavrilovics Csernyisevszkij „Mit tegyek?” kérdésével... A válaszra legnagyobb hatással lévő tényező a média sessionök száma, amelyet a telefonálási platform kezel, vagy amelyet kezelni fog. A számokban és kézzelfogható formában megjelenő jellemző, amely konkrét értékelést ad az említett tényezőről, a CAPS (Call Attempts Per Second) paraméter, vagyis a másodpercenkénti hívások száma. E kérdés megválaszolásának szükségessége elsősorban abból ered, hogy éppen a rendszerbe irányuló sessionok információja fogja terhelni a szerverét.
A második kérdés, amely felmerül a szerver hardverkomponenseinek specifikációjának eldöntése során, a szoftver összetétele (operációs környezetek, adatbázisok stb.), ami rajta fog működni. A jel (vagy média) forgalom a szerverre irányul, ahol egy alkalmazás (például Kamailio) feldolgozza (a jelzőüzenetek bontása) azt, majd a megfelelő módon formázott információt egy adatbázisba helyezik. Különböző SMT-k esetében, mint a jel egységek defragmentálásáért felelős alkalmazások, úgy a tárolást biztosító programok is változóak. Mindazonáltal mindegyiküket a több szálú működés jellemzi. Ezenkívül a SMT infrastrukturális elemének sajátosságai miatt meg kell említeni, hogy a lemezre történő írási műveletek száma jelentősen meghaladja a lemezről történő olvasás műveletek számát.
És végül… „Mennyi minden rejlik ebben a szóban”: szerver, virtualizáció, konténerizáció… Az utolsó, de nagyon fontos aspektus, amelyet a cikk ezen részében érintünk, a SÍK telepítésének lehetséges módjai a telepítési folyamat során. A klasszikus A.S. Puskin idéztel a közvetlen közelben felvetett technológiák széles körben elterjedtek különböző infrastruktúrákban és projektekben. Egyrészt szoros kapcsolatban állnak egymással, másrészt pedig sok szempontból jelentősen eltérnek. Mindazonáltal mindegyikük valamilyen formában elérhetőként van bemutatva a fejlesztők által a termékeik telepítésére vonatkozóan. Az első részben említett rendszerek telepítési módjainak általánosítása érdekében az alábbi lehetőségeket emeljük ki, amelyek fizikai szerverre vagy virtuális gépre történő telepítést szolgálnak:
— automatikus telepítési szkriptek használata, vagy önálló telepítés és a megfelelő szoftver utólagos konfigurálása,
— előre telepített SÍK szoftverrel és/vagy ügynökkel rendelkező operációs rendszer kész képének használata,
— konténerizációs technológia alkalmazása (Docker).
A felsorolt telepítési eszközöknek megvannak a maga előnyei és hátrányai, és a szakembereknek is megvannak a preferenciáik, korlátozásaik és a körülmények, amelyek között az ő általuk használt vagy bevezetett infrastruktúra működik, hogy bármilyen ajánlást megfogalmazhassanak. Másrészt a SIP-forgalom monitorozó rendszerek telepítési módjának leírása megfelelően világos, és a jelen szakaszban nem igényli a részletesebb megvizsgálást.
Egy újabb cikk született a VoIP-hálózatok fontos és érdekes eleméről – a SIP-forgalom monitorozó rendszerről. Mint mindig, köszönöm az olvasóknak az elkötelezett figyelmet! A következő részben még mélyebben foglalkozunk a részletekkel, és megvizsgáljuk a HOMER SIP Capture és a SIP3 termékeket.
Forrás: habr.com
