Cziráky Zoltán, EQUICOM Kft. • Gondolatok a „hálózat lassulás”-ról

Egy felmérés eredményéből világosan álátható, hogy az általánosságban „lassú a hálózat” kifejezés mögött mi a valódi teljesítmény romlás oka. Amint látszik, a kérdés megválaszolása igen nehéz, hiszen a válaszadók közel harmada nem tudta a forrás okot megnevezni. Azonban azok közül, akik meg tudták határozni az okot, több mint fele az alkal-mazásokat tette felelőssé.

Az adatközpont konszolidáció, a hálózati forgalom exponenciális növekedése, valamint az újabb és újabb alkalmazások bevezetése egyre nagyobb kihívások elé állítják az IT infrastruktúrákat és ezzel együtt egyre nagyobb terhet rónak a hálózatgazdákra is. Mind gyakrabban hangzik el a felhasználók részéről a „lassú a hálózat” mondat, mely rengeteg kérdést vet fel:• Valóban lassú?• Valóban a „hálózat”? Vagy inkább a szerver,

az alkalmazás, vagy a kliens?• Kiket érint ez a probléma?

Nagyobb IT szervezetekre különösen igaz, hogy egy ilyen probléma felvetés elindítja az un. forgószék menedzsment gépezetet, ahol a hibajegy kering a különféle IT szervezetek között, de a megoldás csak várat magára.

A közepes és nagyobb hálózatok esetében külö-nösen nagy hangsúlyt kap a hálózat és alkalmazás teljesítmény, hiszen az IT infrastruktúrát szinte közműként használják. Annak kiesése vagy telje-sítmény romlása ugyan olyan hatással van, mintha megszűnne az irodaházban a víz- vagy gázszolgál-tatás. Az IT infrastruktúra teljesítményromlása közvetlen hatással van a felhasználók megelége-dettségére és ezzel a teljes vállalati működés haté- konyságára. Teljesítmény menedzsment nélkül ezen degradálások okának meghatározása napokat, heteket vagy akár hónapokat is igénybe vehet, ami viszont erős kihatással van az üzemeltetési költségekre is.

A felhasználói panaszok és hálózati vagy alkal-mazás lassulások problémájával foglalkozni nehéz feladat az IT üzemeltetők számára, mert:• a teljesítmény szubjektív,• a problémák megjelenése időszakos,• a teljesítményromlásnak rengeteg oka lehet a

teljes alkalmazás-továbbítási láncolatot figye-lembe véve.

Gondolatok a „hálózat lassulás”-ról

1. kép: „Lassú a hálózat”

2. kép: „Hálózat lassulás” valódi oka

2 EQUICOM Méréstechnikai Kft. • © 2012 Minden jog fenntartva • www.equicom.hu

rendszer riasztást küld és azonosítja a hibáért felelős hálózati eszközt. A szolgáltatás kiesésének és a hiba megoldásának idődiagramja az alábbiak szerint néz ki:

A kiesés költsége ilyen esetekben viszonylag könnyen meghatározható, hiszen az alábbi komponensekből tevődik össze:• érintett felhasználók száma x felhasználók

óránkénti költsége x termelékenység veszteség százalékban (pl. a teljes szolgáltatás kiesés esetén ez 100%)

• IT szakemberek száma, akik részt vesznek a probléma megoldásában x szakemberek órán-kénti költsége x az idejük hány százalékában foglalkoztak a konkrét feladattal

• kihatás a vállalat árbevételére.Hálózati vagy alkalmazás teljesítmény csökkené-

sekor a hibakeresés, feltárás, azonosítás és megoldás idődiagramja merőben eltér az előzőekben tárgyal- taktól:

Sok megkérdezett vállalat esetében már az is akár 2-3 napot vesz igénybe, hogy felismerjék a degradációt. A probléma lokalizálásában erős hátráltató tényező lehet a különböző IT csoportok között meg(nem) valósuló kollaboráció. Ez hívjuk „forgószék menedzsmentnek”, amikor a hibajegy körbejár a hálózat-, alkalmazás-, szerver-, munka- állomás-, alkalmazás-, adatbázis-üzemeltetők között. Ezt a fázist gyorsan lezárhatja egy kelle-metlen meeting az IT igazgatóval. Továbbá gondot jelent a megoldáshoz vezető úton az is, hogy ezek a problémák sokszor időszakosak. A hálózati és/vagy alkalmazás degradációk megoldása könnyedén lehet akár 1-2 hét is.

Egy alkalmazás és/vagy hálózati teljesítmény monitorozó rendszer bevezetésekor rengeteg mérlegelendő feladat és megválaszolandó kérdés előtt állnak az IT menedzserek:• Költség és megtérülés: összemérhető-e a rendszer

bekerülési és üzemeltetési költsége a hálózat kiesések illetve teljesítmény csökkenések okozta költségnövekedéssel?

• Technológia: a különféle technológiai megközelí- tések közül melyik felelne meg leginkább a vállalat elvárásainak? Alkalmas-e a rendszer az új kihívások (pl. virtualizáció) támogatására?

• Bevezetés: a rendszer bekerülési költségein túl milyen telepítési és képzési feladatok várnak az üzemeltető csoportra?

• Üzemeltetés: a rendszer bevezetésével javul-e az IT csoport hatékonysága vagy éppen még több feladatot ró rájuk a menedzsment rendszer üze- meltetése?

• Integráció és riportok: megvalósítható-e az újonnan bevezetett rendszer integrációja a már meglévő BSM/OSS rendszerekbe?

Vizsgáljuk meg a fenti kérdések közül a legfontosabba-kat kicsit részletesebben.

Költség és megtérülés

Annak meghatározása, hogy hozzávetőlegesen milyen költségekkel jár a hálózat vagy egy kritikus alkalmazás teljes kiesése a vállalat számára, talán még egy könnyebben megválaszolható kérdés. Azonban azt meghatározni, hogy a hálózat vagy az alkalmazások teljesítmény csökkenése és a költségek milyen arányban állnak egymással, már sokkal összetettebb kérdés, hiszen ez vállalaton-ként nagymértékben eltérő. A költségeken és a puszta számokon túl azonban sok egyéb össze-tevőt is figyelembe kell venni, amikor az N/APM (Network/Application Performance Management) megtérülését vizsgáljuk. Ilyenek például a külön-böző IT osztályok (hálózatos, szerverüzemeltető, alkalmazásos, IT biztonság) közötti kollaboráció, a menedzsment felé biztosítandó riportok, az MTTR (mean time to repair) idők csökkentésére irányuló törekvések, stb.

A hálózat vagy egy adott alkalmazás teljes kiesé- sekor a felhasználók munkája teljesen lehetetlenné válik, az egyszerű (pl. SNMP alapú) monitorozó

3. ábra Idődiagramm szolgáltatás kiesés esetén

4. ábra Idődiagramm teljesítmény csökkenés esetén

Cziráky Zoltán, EQUICOM Kft. • Gondolatok a „hálózat lassulás”-ról

Ha ennek költségeit csak az előzőekben is tárgyalt összetevők alapján határozzuk meg, és figyelmen kívül hagyjuk az egyéb összetevőket, akkor is akár 4-5-szörös költséget jelent.

Amennyiben egy N/APM rendszer képes a fenti idődiagram egyes fázisain számottevően zsugorí-tani, kézzel fogható megtérülés számolható, mely a felmérésben részt vevő vállalatok esetében átlagosan évi néhány $100.000 volt.

Technológia

Alkalmazás teljesítmény menedzsment rendszerek esetében három különféle technológiai megoldásról beszélhetünk:• Felhasználói megelégedettség (EUE: end-user

experience) monitorozása: a hálózaton elhe-lyezett „robotok” generálnak előre konfigurált mérőforgalmat, mellyel vizsgálja a felhasználók által tapasztalható tranzakciós időket.

• Agent alapú APM rendszerek: az alkalmazás

5. ábra APM technológiák

szervereken futó agent-ek monitorozzák az adott alkalmazást kód és rendszer erőforrás szintjén

• Hálózat alapú APM rendszerek: a hálózat külön-böző pontjain elhelyezett probe-ok elfogják a forgalmat a kliens és a front-end szerverek között, vagy az alkalmazási láncban

Hasonlítsuk össze az egyes technológiák előnyeit és hátrányait táblázatos formában:

APM típusa Felhasználói megelé-gedettség (EUE) monitorozása

Agent alapú APM rendszerek

Hálózat alapú APM rendszerek

Mire ad választ?

• Mennyire elégedettek a felhasználók a kritikus alkalmazások teljesítő-képességével?

• Az alkalmazási lánc mely eleme okozza a lassulást?

• Mely alkalmazás mely része okozza a lassulást?

• Van lassulás? És ha van, kiket érint?

• Mi okozza a lassulást (szer-ver, alkalmazás, hálózat)?

• Melyek az érintett tranzakciók?

Limitációk • Nem tükrözi a valós használatot.

• Nem mutat rá a hiba valódi okára.

• Nem látszik az alkalmazás továbbításáért felelős hálózat egésze.

• Ha a szerveren futó alkalmazás kódban van a hiba, az láthatatlan marad.

Kötöttségek • Agent minden kliensen.

• Minden egyes szkenárió külön felkonfigurálása.

• Minden szerveren egy agent fut, mely befolyásolhatja a szerver teljesítményét.

• SPAN port vagy TAP a forgalom elkapásához.

Terület • Csak néhány kritikus alkalmazásra.

• Csak néhány kritikus alkalmazásra.

• Az összes hálózati alkalmazásra.

Felhasználók • Főként helpdesk. • Fejlesztők. • Infrastruktúra csoport, help-desk.

4 EQUICOM Méréstechnikai Kft. • © 2012 Minden jog fenntartva • www.equicom.hu

További kérdés az alkalmazott technológiával kapcsolatban, hogy képes lesz-e kiszolgálni a hálózat bővülését, változását továbbá az újonnan megjelenő technológiákat.

Tehát az alkalmazott rendszernek olyan stan-dardizált komponensekből kell összeállnia, hogy hálózat bővítéskor vagy átstrukturáláskor a leg-kisebb költséggel és energia ráfordítással kelljen csak számolni. Ilyen esetekben is nagy előnyt jelen-tenek a hálózat alapú APM rendszerek, ugyanis ezeknél a hálózati topológiától függetlenül hasz-nálhatók az úgynevezett probe-ok vagy pollerek, melyek egy hálózati eszköz SPAN portján vagy egy hálózatba iktatott TAP-en keresztül férnek hozzá a forgalomhoz. Ez a tradicionális technológia semmi-ben nem különbözik a protokoll analizátorok általhasznált megoldástól. Az adatgyűjtést a hálózat bármely pontján el lehet végezni, majd az összegyűjtött információkat egy központi kollek-torba eljuttatva lehet megjeleníteni.

Felmerülhet a kérdés, hogy hogyan képesek ezen rendszerek pl. virtuális szerver környezetben a virtuális gépek közötti forgalom felügyeletére.Ez természetesen csak virtuális technológiával való-sítható meg, hiszen az alkalmazások és tranzakciók egy része a virtualizált rendszereken belül marad, nem halad át fizikai hálózaton. Ahhoz, hogy ezen hálózati forgalmakat felügyelni tudjuk, minden-képpen meg kell „csapolni” a virtuális hálózati architektúrát.

Erre három megoldás létezik:

Promiscuous (válogatás nélküli) üzemmódA portok egy csoportjának vagy a virtuális switch promiscuous módban történő használatával egy Virtuális Appliance képes a forgalom elfogására, feldolgozására. Ennek a megoldásnak a hátránya, hogy adatbiztonság tekintetében felmerülhetnek kétségek.

Port tükrözés a virtuális switch-enGyártótól függően (pl. Vswitch, Openvswitch, Virtual Distributed Switch Cisco Nexus, HP Connect) a virtuális switch-ek képesek a port tükrözésre, a fizikai switch-ekhez hasonlóan. Ezen megoldások egy része elérhető nyílt forráskódú változatban is, mások licenchez kötöttek.

Virtuális TAPA harmadik megoldás a dedikált virtuális TAP hasz- nálata, amely egyszerűen továbbítja az elfogott forgalmat az analizátor felé, hasonlóan fizikai társaikhoz. Ez egy kétségtelenül elegáns megoldás, azonban szükséges a VMware certifikáció a haszná- latához.

Az alábbi felmérés eredményéből jól látható, hogy a virtualizáció mellett az IP alapú hangátvitel is egy kiemelkedően fontos technológia nem csak a meglévő, de a jövőbeni fejlesztési irányok tekin-tetében is.

6 ábra Elosztott hálózati APM architektúra

7 ábra IT infrastruktúra projektek

Cziráky Zoltán, EQUICOM Kft. • Gondolatok a „hálózat lassulás”-ról

APM rendszerek bevezetése és üzemeltetése

A megfelelő technológia kiválasztása még nem garancia arra, hogy a rendszer zökkenőmentesen használható is lesz. A „Költség és megtérülés” részben nem foglalkoztunk részletesen a bevezetés költségeivel, azonban ez sem elhanyagolható része a teljes rendszer beruházásnak. Ha a felhasznlók-nak több napos vagy hetes képzésen kell részt venniük, hogy a rendszert rugalmasan tudják használni, vagy sok-sok órás konzultációs díjjal lehet csak a megvásárolt rendszert működésre bírni, az bizony komoly extra költségekkel járhat. Továbbá személyes tapasztalatunk, hogy bármilyen kiváló rendszerrel is áll szembe a majdani felhasz-náló sokat ront a megítélésén, ha a rendszer üze-meltetése többlet feladatokat hárít rá.

Ezeket a kérdéseket csak úgy tudjuk magabiz-tosan megválaszolni, ha teljes körű teszteket tudunk végrehajtani a kiszemelt rendszerrel, ráadásul a saját hálózati környezetünkben. Egy pilot projekt keretében azonnal láthatjuk, hogy milyen energia- ráfordítás szükségeltetik a rendszer hadra fogásá-hoz, ez mennyi időt vesz igénybe, illetve az üze-meltetése igényel-e többlet munkaidő ráfordítást.

Integráció és riportok

Nagyon kevés olyan rendszer létezik a piacon, amelyek képesek egy IT infrastruktúra minden egyes komponensére teljes körű megoldást kínálni. Olyan rendszer meg szinte nem is létezik, mely minden feladatra a legjobb választás lenne. Éppen ezért csak olyan megoldásban szabad gondol-kodnunk, amely lehetővé teszi az integrációt a már meglévő vagy a későbbiekben kialakítandó BSM (Business service management) vagy OSS (Operations support system) rendszerekhez. A leg-egyszerűbb és szabványosított integrációs lehető-séget az SNMP támogatás nyújtja számunkra. Azon gyártók termékei, amelyeknél lehetővé teszik az SNMP MIB (management information base) adatbá-zishoz való hozzáférést, könnyedén integrálhatóak akár olyan nyílt forráskódú menedzsment rendsze-rekhez, mint pl. a Nagios, Zabbix, vagy Cacti.

Egy 2010-es felmérés szerint a válaszadó válla-latok 71%-a rendelkezett valamilyen SNMP konzollal, de mindössze 21%-uknak volt alkalmazás teljesít-mény vizsgálatra megoldása. Kézenfekvő a törek-vés, hogy a meglévő SNMP alapú hálózat/eszköz monitorozó rendszerekbe integráljuk az APM megoldásunkat.

További követelményként merülhet fel a rend-szer riportolási képessége. Más igények merülnek fel a hálózat üzemeltetők részéről, megint más a fejlesztőktől, de nem szabad megfeledkezni a vezetői kimutatásokról sem.

A hibaforrások mély szintű analíziséhez elenged- hetetlen az alkalmazások és tranzakciók protokoll elemzése. Egy korszerű APM rendszer lehetővé teszi, hogy a már jól megszokott protokoll elemző meg-oldásunkat használhassuk, hiszen az előző felmérésből

8 ábra APM rendszerekbevezetési és üzemeltetési költségei

9 ábra Milyen menedzsment eszközt használ?

6 EQUICOM Méréstechnikai Kft. • © 2012 Minden jog fenntartva • www.equicom.hu

is jól látható, hogy a válaszadók 60%-a már rendel- kezik ilyen megoldással. Amikor az APM rendszerünk rámutat egy hálózat lassulás valódi okára, felme-rülhet az igény a capture fájl részletes elemzésére, mellyel akkor van a legkönnyebb dolgunk, ha az egy szabványos formátum (pcap – packet capture), így harmadik gyártó által fejlesztett elemző alkalma-zásban is megnyitható, elemezhető.

Konklúzió

Az eddigi gondolatokból látható, hogy a „lassú hálózat” oka az esetek nagy részében nem magára a hálózat teljesítményére vezethető vissza, hiszen a teljes alkalmazás továbbító lánc az újabb és újabb technológiáknak köszönhetően igen összetett, sok különféle alkotó elemet tartalmaz.

Annak érdekében, hogy pontosan meghatároz- hassuk a lassulások és teljesítmény romlások valódi okát, APM rendszer bevezetésére van szükségünk. Ez azonban rengeteg kérdést vet fel, és a rendel-kezésre álló rendszereket több aspektusból kell vizsgálnunk, hogy a számunkra leginkább megfelelőt választhassuk.

Ha Ön is hasonló problémákkal küzd mindennapi munkája során, kérje az EQUICOM Méréstechnikai Kft. munkatársainak segítségét.www.equicom.hu

EQUICOM Méréstechnikai Kft. © 2012 Minden jog fenntartva Jelen kiadvány a jogtulajdonos írásos engedélye nélkül sem részben, sem egészben nem másolható, sem elektronikus, sem mechanikus eljárással, beleértve a fénymásolást, számí-tógépes rögzítést is.