A wifi nem luxus és iroda. Ma már elképzelhetetlen nélküle, de egyre jobban igaz ez a gyárak, ipari területek tekintetében is. Sok irodában már nem is nagyon terveznek vezetékes végpontokkal, ezáltal megtakarítva például a kiterjedt kábelezés költségét és a felhasználók számával egyelő portmennyiséget. Érthető az az igény, hogy miért kell ennek megbízhatóan működnie.
És itt máris tegyünk különbséget aközött hogy valami működik és hogy valami használható. A wifire vetítve ez körülbelül:
- működik: lehet rá csatlakozni
- használható: lehet rá csatlakozni + elérni a szükséges alkalmazásokat/szolgáltatásokat a segítségével
Magyarország nem az ITO országa, mármint van nálunk nagyon sok SSC, de alapvetően a cégek ritkán szervezik ki informatikájukat. Amennyiben mégis vagy például a vállalati wifi üzemeltető csapat nincs ott minden lefedett irodában/gyárban/ipari területen, akkor esetükben kimerül a hibakeresés és egyáltalán a hiba behatárolása abban, hogy egy adott AP-t megnéznek működik-e, szórja-e az SSID-t, milyen csatornán van, eléri e a wireless controller-t. Esetleg ha több AP van, akkor csinálnak egy spektrum analízist, de alapvetően ezekkel nem a felhasználó szemszögéből keresik a problémát. Picit másképp kifejezve, nem kliensként közelítik meg és próbálják megtalálni a hiba forrását, hanem éppen a kiszolgálói infrastruktúra felől.
Aruba User Experience Insight – aka Cape Networks
Na itt jöhet képbe az Aruba User Experience Insight. Ez lényegében egy átnevezett Cape Networks megoldás, amelyet a HPE a vásárlás után a portfóliójába emelt. Ennek elengedhetetlen része a szenzor, amely körülbelül egy apróbb méretű AP-val ekvivalens méretű.
Egy/több ilyen szenzorral real time monitorozható a wifi hálózat és az azt kiszolgáló rendszerek működése és bizonyos esetekben teljesítménye (válaszidő, wifi specifikus értékek mint zaj, retry rate stb). Ha például ezeket a szenzorokat fix helyre szerelik, akkor körülbelül úgy viselkedik, mintha egy felhasználó éjjel-nappal a laptopja előtt ülne és a wifi hálózaton keresztül tesztelgetné másodpercenként az általunk beállított szolgáltatásokat és rögzítené a hálózat jellemző paramétereinek értékeit.
Ha nem szereljük fel ezeket az eszközöket, hanem abban az esetben kerül ki például a problémát jelentő felhasználó asztalára, aki a hibás működést jelzi, akkor igen jó eszközt kaphatunk a nehezen behatárolható és mobilis problémák kezelésére.
Hogy működik és hogy kell bekötni?
Ez egy felhős megoldás, tehát maga a szenzor mindent a felhőbe továbbít, illetve értelemszerűen onnan kapja a konfigurációját. On premises verzió nincs, csak felhős.
Sok csatlakozó nincs rajta, csak egy PoE képes Gigabites Ethernet (10/100/1000) és egy külső tápcsatlakozót találunk rajta. Most felmerül a kérdés, hogy ha ez egy wifi szenzor, akkor minek rá a rezes port.? A magyarázat annyi, hogy különböző teszteket végre lehet vele hajtatni mind wifin, mind vezetéken, illetve a menedzselhetősége a wifit érintő teljes probléma esetén, illetve ha például a monitorozott wifiről nem elérhető az internet, akkor lehetetlen, szint úgy nem tudja jelenteni majd az alert-eket a felhős komponensnek.
Van benne egy SIM is (3G/LTE), amivel még inkább függetleníthető mindenféle monitorozott hálózattól és kapcsolattól. Tehát akkor is képes információkkal és riasztásokkal szolgálni, ha éppen teljesen áll mindenféle kapcsolat, a mobilhálózaton keresztül az eszköz elérhető marad. Maga az eszköz előfizetése tartalmaz minden költséget ami a SIM használatához kell és havi 5MB adatforgalmat is. Ezen felül kérhető hozzá korlátlan csomag is.
A felhős dashboard
Az authentikáció után egyenesen a fő dashboard-ra jutunk, ahol eléggé nyilvánvaló módon lehet megyőződni a helyes vagy hibás működésről.
Az experience általánosan jelzi, hogy minden rendben van e. A Services rész az általunk beállított szolgáltatások állapotát jelzi, azaz hogy azok tesztelése adott-e vissza hibát vagy sem. Az Internal résznél például a wifi-n vagy vezetékes hálózaton elérhető vállalati/belső szolgáltatásokat lehet áttekinteni – később hozok létre pár ilyen tesztet. Az External ezzel szemben a külső szolgáltatások állapotát jelzi, így például, hogy elérhető-e a külső vállalati weboldal – 99999.hu – vagy pélául az O365.
Ha valamelyikre rákattintunk, például a Wi-Fi-re, akkor megnyílik egy ablak, ami lehetőséget ad mélyebb betekintésre és bizonyos időszakra történő szűrésre. Alább az elmúlt hét nap látható és az 5 percenként végrehajtott tesztek eredményeiből álló diagram. Látható, hogy mikor melyik csatornán volt az AP, milyen volt a csatorna kihasználtsága és például az AP-hoz történő kapcsolódásnak szükséges ideje. A bal alsó ablakban egy idővonalon elhelyezve mutatja az alerteket és hogy mikor fordultak elő.
Az egyik ilyen alertre rákattintva részletesebb információt is ad:
A fő dashboard-on a Services-nél pédául a 99999.hu-ra kattintva megmutatja az elvégzett tesztek alapján kapottakat. Beállítható természetesen miket nézzen, alább a 80-as, 443-as portokon vizsgál elérhetőséget, HTTP kódokat néz amit a weboldal visszaad, és validálja az SSL certificate-et is – szóval ha lejár, akkor szerencsére szólni is fog. Tesztel ping-gel, méri a HTTP kérés kiszolgálási idejét is.
Beállítások
Az első menü a szenzorok listája, illetve a csoportok. Egy vagy több szenzort csoportokba rendezhetünk ezáltal a tesztek hozzárendelését kicsit könnyebb elvégezni, ha több szenzoron is akarjuk őket futtatni.
A következő tab a networks, itt lehet megadni a figyelni kívánt wifi hálózatokat, illetve vezetékes beállításokat. Konfigurálható proxy is, ha például az kell az internet eléréséhez.
A testing tab szolgál arra, hogy a külső és belső szolgáltatásokat és az azokon elvégzendő teszteket beállítsuk. A felső rész a belső, az alsó szekció a külső teszteket jelenti.
A thresholds szekció az alerting finomhangolására szolgál, beállítható hogy egy SSID eltűnése esetén mikor jelezzen és mikor adjon riasztást, de egyébként elég sok eseményre tud reagálni.
Az alert részen lehet azt megadni, hogy a threshold-ok alapján történő jelzésekekel mi történjen. Publikálja e külső forrásra (Slack, ServiceNow, Iris) küldjön-e levelet, heti riportot, főzzön-e kávét.?
Hozzunk létre egy tesztet
Egy weboldalra definiálok egy tesztet. Lentebb ez egy external teszt lesz és custom – mivel a predefined alatt az ismertebb publikus szolgáltatók vannak. Látható, hogy iPerf teszteket is végre lehet hajtatni belső/külső terheléses teszteket. A generic-nél be lehet állítani a kívánt portokat, a webserver-nél pedig az ismertebb lehetőségeket adja.
Ezt kiválasztom:
Pár perc múlva már meg is jelennek az első eredmények.
Real life test
Ezen cikk írása közben, valami probléma adódott az internet felé menő irodai kapcsolatunkkal, így jó alkalom adódott az éles tesztelésre.
A dashboard jelzi a felhasználók általános arckifejezését és azt, hogy a wifi, a vezetékes hálózat, a DHCP és az alapértelmezett átjáró mind vezetékes, mind wifi hálózaton hibátlan, viszont a DNS-sel gond van.
A DNS-re kattintva megnyílik egy összefoglaló, látható mikor kezdődött a probléma.
Az Ongoing mutatja hogy a probléma éppen fennáll, arra rákattintva részletesen nyílik meg, hogy mennyi tesztet végzett el a szenzor. Megnézi a konfigurált DNS-t a cloudflare-es DNS-eket, traceroute-ot futtat.
A probléma forrása a DNS kiszolgáló elérhetetlensége, minden más rendben van. A probléma elhárítása után, azonnal jelezte, hogy minden megfelelően működik, sőt mi több, automatikusan “Resolved” állapotba teszi az alert-et, viszont megőrzi a hiba alatt elvégzett tesztek eredményeit – ami fent látható csak Ongoing helyett Resolved-et ír.
Összefoglaló
Szerintem egy végtelenül hasznos, a hibakeresést és egyáltalán az üzemeltetést megkönnyítő megoldással szolgál az Aruba Experience Insight. Lehet nélküle élni persze, de amennyiben valaki azonnal értesülni szeretne, akár több telephelyről, több hálózatból a szolgáltatások és az infrastuktúra aktuális állapotának változásáról és nem megvárni a felhasználói panaszokat, azoknak érdemes megfontolni egy-két ilyen szenzor beszerzését és subscription vásárlását.
