Kliensfelügyelet Microsoft módra

Ma már szerencsére vitán felül áll, hogy a nagy komplexitású, üzleti szempontból kritikus rendszereket csak automatizált és intelligens felügyeleti eszközökkel lehet eredményesen, és megbízhatóan üzemeltetni.

A végfelhasználói rendszerek tekintetében azonban korántsem ilyen egyértelmű a kép: az irodákban, üzemekben található, vagy az éppen úton lévő munkatársaink gépeinek felügyelete általában nem megoldott, és még abban sincs mindig egyetértés, hogy milyen szorosan kell ezeket a rendszereket felügyelni. A következő írásban néhány érvet szeretnék felsorolni a kliens rendszerek monitorozása mellett, illetve igyekszem bemutatni azokat a lehetőségeket, amelyeket a Microsoft System Center Operations Manager 2007 (SCOM2007) nyújt a kliens környezet felügyeletére.

Miért is fontos a klienseket felügyelni?

Nemzetközi felmérésekben megdöbbentő számokat találhatunk arról, hogy a felhasználók és gyakran még az üzemeltetők is hogyan viszonyulnak az asztali operációs rendszerek, és a rajtuk futó alkalmazások felügyeletével, támogatásával kapcsolatos problémákhoz. A felmérések szerint a gépeken bekövetkező hibák 90 százaléka nem jut az üzemeltetésért felelős szervezet tagjainak tudomására. A felhasználók egy-egy váratlan alkalmazás, vagy operációs rendszer hiba esetén a leggyakrabban megelégszenek a rendszer újraindításával, és reménykednek abban, hogy ez a hibákat is megoldja. (Valljuk be őszintén, ezt gyakran magunk is megtesszük.) A fennmaradó 10 százaléknyi hiba felét, tehát 5 százalékot a helyi ügyfélszolgálat valamilyen formában (tüneti kezeléssel, vagy szintén újraindítással) kezeli, és csak a fennmaradó 5 százalék jut el az kliens környezet kialakításáért, naprakészen tartásáért felelős szakemberekig.

Ezek az adatok többszintű üzleti és üzemeltetési kockázatra hívják fel a figyelmet. Az első szinten a rejtve maradó incidensek munkakiesést okoznak, esetleg fontos adatok elvesztésével járnak, a felmerült hiba nem jut az üzemeltetők tudomására, és így hosszú távú felszámolása sem lehetséges. A második szinten pazarlásnak tekinthetjük azt az időt, amit az ügyfélszolgálat munkatársai a visszatérő, de véglegesen meg nem oldott hibák ismétlődő elhárítására fordítanak. A harmadik szinten a kliens architektúráért felelős rendszergazda számára az egyesével felmerülő incidensek nem könnyítik meg a probléma gyökerének meghatározását, és -- kevés kivétellel -- szinte lehetetlen az incidenseket a változáskezeléshez kötni, így azonosítva az esetleges sikertelen változtatások tüneteit.

Komoly hibát követnénk el, ha a felhasználókat tennénk felelőssé egy ilyen helyzet kialakulásáért. Az angol terminológiában Information Workernek (magyarul általában infomunkásnak fordítjuk) nevezett csoport tagjai nem hivatásos informatikusok, nem várhatjuk el tőlük a gépeiken bekövetkező hibák szakszerű elemzését. Az infomunkás közösség egyik legfontosabb jellemzője, hogy a tagok egyéni informatikai ismeretei rendkívül eltérőek lehetnek, hiszen infomunkások például azok a pénzügyi elemzők, akik összetett, dinamikusan változó Excel tábláikat Office Sharepoint Excel Services segítségével osztják meg egymás között, de infomunkások azok is, akik egy üzemi területen a termelés alapvető adatait viszik fel, vagy követik egy erre a célra rendszeresített felületen keresztül.

Az informatikai üzemeltetés szempontjából viszont a csoport minden tagja ügyfél, aki iránymutatást, támogatást, világosan követhető eljárásokat és segítséget igényel, az általuk használt rendszerek pedig felügyeletet. Ezen rendszerek szorosabb és hatékonyabb felügyeletét még további szempontok is indokolják, ezek közül a legfontosabbak a következők:

Üzleti szempontok	Technológiai szempontok
Infomunkások által használt számítógépek is lehetnek kritikusak az üzletvitel szempontjából, például: * gyártási folyamatok irányítására használt gépek * üzemi vagy pénzügyi tranzakciókra egyedileg konfigurált gépek * vezetők által használt gépek	Az infomunkások által használt infrastruktúra a rendszereinket kívülről és belülről fenyegető támadások elsődleges forrása: * az infomunkások munkájuk során használják az internetet, weblapokat látogatnak, email-eket küldenek és fogadnak -- gépeiket megfelelő módon védeni kell a veszélyekkel szemben, illetve a megfelelő felügyelettel garantálható az esetleges támadások, fertőzések korlátok között tartása * a vállalat által bizalmasnak vagy titkosnak tekintett információk jellemzően az infomunkások gépein keresztül hagyják el a védett hálózatot (általában valamilyen adathordozón), aminek kockázatát megfelelő korlátozásokkal (például csoportházirendekkel) lehet csökkenteni és a korlátozások meglétét felügyeleti eszközökkel ellenőrizni.
Az informatikai szolgáltatások széleskörű megítélése és így az IT szervezet munkájának megítélése is a vállalaton belül általában az infomunkások napi személyes tapasztalatain alapul.	Az infomunkások gépein jelentkező hibák jelentős része előre jelezhető és az incidens bekövetkezése előtt megelőzhető. A megelőző tevékenység jelentősen csökkentheti a tényleges incidensek számát és javíthatja az IT szolgáltatás megítélését (lásd a baloldali oszlop).
Az informatikai rendszerek egy része (így bizonyos infomunkások által használt gépek is) a vállalat ügyfelei, partnerei számára is látható lehet. A szolgáltatás akadozása, megbízhatatlansága kedvezőtlen képet alakíthat ki a vállalatról, ami jelentős üzleti hátrányt is okozhat.	Az infomunkások gépein bekövetkező hibák tervszerű és következetes összegyűjtése segíthet feltárni a kliens környezet tervezése és megvalósítása során elkövetett esetleges hibákat, illetve segítheti az egyes alkalmazások fejlesztőit, szállítóit az alkalmazáshibák kijavításában.

Már a fenti érvek alapján is belátható, hogy az infomunkások által használt infrastruktúra tervszerű és következetes felügyelete nagyon is szükséges, nézzük tehát, milyen eszközöket kínál erre a feladatra a System Center Operations Manager 2007.

Ügynökeink jelentik

Elsődleges feladatunk, hogy bekapcsoljuk a SCOM2007 kliensfelügyeleti funkcióit, alapértelmezés szerint ugyanis ez a funkció nincs engedélyezve. Ha több Management Serverünk van -- ami egy nagyobb környezet esetén szükséges is -- akkor azt is kiválaszthatjuk, hogy mely kiszolgálókat akarjuk a kliensfelügyeletre specializálni. A bekapcsolás egy varázsló futtatásával történik, a felügyeleti konzol adminisztrációs (Administration) lapján keresztül. Miután kiválasztottuk a kliensfelügyeletre szánt Management Servert, annak Tulajdonság lapján (Properties) tudjuk a varázslót elindítani.

A funkciót bekapcsoló varázslóban meg kell adnunk a felügyelt gépek halmazát (inclusion range), praktikusan egy LDAP lekérdezés formájában. Ha például az adott telephelyen minden gépünk neve BP-vel kezdődik (pl. budapesti telephely esetén), akkor ez a lekérdezés valahogy így nézhet ki: (&(sAMAccountType=805306369) (objectCategory=computer)(samAccountName=BP*)).

Szükség esetén kivételeket is meghatározhatunk (exclusion range), ezen gépek nem kerülnek a SCOM2007 ellenőrzése alá. A varázsló utolsó lépésében lehetőségünk van arra is, hogy egy tartalék Management Servert jelöljünk ki arra az esetre, ha az elsődleges nem elérhető (failover server).

Ha fellapozzuk a SCOM2007-hez rendelkezésre álló felügyeleti csomagok (management packs) katalógusát, akkor a következő csomagokat találjuk, amelyek valamilyen formában a kliens infrastruktúra felügyeletét szolgálják:

• Windows Client 2000 Professional Operating Systems
• Windows Client XP Professional Operating Systems
• Windows Client Business Critical Operating Systems
• Windows Vista Monitoring Pack
• Information Worker Office 2007
• Information Worker Windows and MSN Messenger
• Information Worker Windows Explorer
• Information Worker Windows Media Player
• Information Worker Internet Explorer
• Microsoft Windows Server Group Policy 2003 (MOM 2005-ről konvertált csomag)

(A listában csak a specializált csomagokat soroltam fel, a működésükhöz szükséges háttércsomagokat -- amelyek nagyobb része alapértelmezésben települ is -- nem.)

A csoportházirend-felügyeleti csomag felépítése

A felsorolás egyetlen "fekete báránya" a csoportházirendek felügyeletét szolgáló csomag, ami részben a kiszolgáló infrastruktúrát is lefedi, viszont elengedhetetlen információkat szolgáltat a mi érdeklődésünk központjában álló környezetről is. Amint az a 2. ábrán látható struktúrából is kitűnik, a felügyeleti csomag egy könnyen áttekinthető rendszerben mutatja a csoportházirendekkel kapcsolatos fontosabb eseményeket (sikeres, sikertelen alkalmazás, figyelmeztetések). Fontos információkkal szolgálhat ez a felügyeleti csomag az infomunkás környezet működésében tapasztalható rendellenességek gyökereiről, amelyek sok esetben a csoportházirendek elmaradó, vagy hibás kiértékelődéséből erednek.

Az asztali operációs rendszerek és az azokon futó alkalmazások felügyeletére szánt csomagok egymásba ágyazottan jelennek meg miután importáltuk őket és alkalmazni is hierarchikus rendszerben érdemes őket. Az üzletmenet szempontjából kevésbé kritikus számítógépek esetében választhatjuk az ügynök nélküli üzemmódot (Agentless Monitoring). Ebben az esetben a SCOM csak a legkritikusabb eseményeket és teljesítménymutatókat figyeli, és rögzíti (teszi ezt hagyományos teljesítmény számlálókon és a Windows Error Reporting funkción keresztül ez régi barátunk, dr. Watson utódja). A gépekre nem kerül semmilyen a SCOM2007-hez tartotó komponens, így nincs szükség ezek frissítésére és karbantartására sem. A rendszerekről összegyűjtött hibaadatokat elemezhetjük magunk, vagy továbbíthatjuk (automatikusan is) a Microsoftnak.

A viszonylag nagyszámú, megfelelően rögzített (gépnévvel, időbélyeggel ellátott) adat alkalmas a legfontosabb tendenciák azonosítására és ezek riportokba történő összefoglalására. Mivel az ügynök nélküli mód egészen minimális kezdeti konfigurálást és utánkövetést igényel, ezért bátran kiterjeszthetjük a teljes szervezetre. A SCOM moduláris jogosultsági rendszerén keresztül pedig akár külön informatikai szervezeti egységhez delegálhatjuk a kliens gépek felügyeletét.

A kliensfelügyelet legfelső szintű eszközei

A második szinten már szelektív monitorozást alkalmazunk azon kliensek esetében, amelyeket szigorúbb felügyelet alá szeretnénk vonni. Ebben az esetben már ügynököt (SCOM Agent) kell alkalmaznunk, ami azzal az előnnyel is jár, hogy az események gyűjtése független attól, hogy az adott gép éppen elérhető-e a fölérendelt Management Server számára. Ez a megoldás hasznos lehet például notebookflottánk szemmel tartására. Az ügynökök -- miután helyreállt a kapcsolat a Management Server felé -- részletes adatokat továbbítanak a felmerült hibákról, a használat során mért teljesítmény- és megbízhatósági adatokról, amiket azután akár összesített jelentésekhez is felhasználhatunk. A rendelkezésre álló adatok olyan részletesek, hogy megállapíthatjuk például a gépekben használt merevlemezek megbízhatóságát gyártónként és típusonként.

Ezen a felügyeleti szinten már rendelkezésre állnak a távoli felügyeleti eszközök is (miután a tűzfalakat a megfelelő csoportházirendekkel beállítottuk), így a távoli segítség és a távoli asztal is. Az eseménynaplók és a szolgáltatások közvetlen elérése és konfigurálása mellett integráltan használhatjuk a Powershell szinte kimeríthetetlen lehetőségeit az egyes gépek, vagy gépcsoportok lekérdezésére, átkonfigurálására.

A harmadik szinten az üzleti szempontból kritikus jelentőségű gépeinket felügyelhetjük, még az előző csoportnál is szigorúbb szabályok szerint. Ezen gépek esetében már megfontolásra érdemes a SCOM2007 Audit Collection funkciójának bekapcsolása, hogy a bekövetkező biztonsági események központi rögzítésre és feldolgozásra kerüljenek. Szükség szerint létrehozhatunk olyan szintetikus alkalmazás objektumokat is, ahol a kritikus alkalmazások elérhetőségét a végfelhasználó perspektívájából figyelhetjük, így hiba esetén csak a felhasználó útját kell végigkövetnünk a hiba helyéig.

Cikkünk még nem ért véget! >>>

[oldal:Milyen adatokhoz juthatunk hozzá?]

Az operációs rendszerek felügyeleti csomagjai -- a Vista kivételével -- csak az operációs rendszerek néhány alapvető tulajdonságát és teljesítménymutatóit gyűjtik össze. A Windows Client State opció áttekintő képet ad a felügyelt rendszerek általános egészségi állapotáról, illetve a rendszerek alapvető tulajdonságairól, pl. DNS és NetBIOS név, IP cím, elhelyezkedés az Active Directory struktúrában. Ha ugyanezt a gépet a Monitoring/Computers opció alatt választjuk ki, akkor pedig láthatjuk a legfontosabb hardver eszközök (CPU, memória, hálózati interfész, diszkkonfiguráció) , az operációs rendszer (verzió, szervizcsomag) tulajdonságait.

A Windows Client State áttekintő képe

Az egészségi állapotot részleteiben is elemezhetjük, ha az adott gép kiválasztása után a jobb egérgombbal előhívható helyi menüből a Health Explorer opciót választjuk ki. A megjelenő részletes elemzés nemcsak azt mutatja meg, hogy az adott gép milyen állapotban van, illetve hogy az egyes megfigyelt komponensek milyen változásokon mentek át a megfigyelt időszakban, hanem egyben megmutatják a SCOM2007-ben bevezetett Health Model belső struktúráját is.

Egy Windows XP számítógép Health Modelje és a processzor használathoz tartozó tudnivalók

A gép vagy alkalmazás egészségi állapotát meghatározó mutatókat hierarchikus rendbe szervezve találjuk (nem nehéz felismerni a háttérben meghúzódó XML struktúrát), négy kulcsfontosságú főcsoport alatt. A négy főcsoport a Rendelkezésreállás (Availability), a Konfiguráció (Configuration), a Teljesítmény (Performance) és a Biztonság (Security). Ezekben a csoportokban találjuk három-négy további szinten tagolva a különféle felügyelt komponenseket és az előttük látható piktogramokról egyben leolvashatjuk aktuális állapotukat is.

Az egészségi mutatók változásának története

Ha az alsóbb szinteken kiválasztunk egy-egy komponenst, a képernyő jobboldali mezőjében megjelenik az adott komponenshez tartozó háttérinformáció (Knowledge), ami segít abban, hogy megértsük miért is fontos az adott komponens felügyelete, melyek az egészséges állapothoz tartozó határértékek, mi okozhat eltérést a beállított értékektől és ilyen esetben mi a teendő. A lap tetején található State Change Events fülre váltva pedig láthatjuk az adott komponenshez tartozó események időrendjét: mikor, milyen állapotváltozások következtek be az adott komponensen.

A Health Modelben minden megfigyelt elemhez három lehetséges állapot tartozik: a zöld, ami az elvártnak megfelelő működés; a sárga, ami kisebb rendellenességet mutató, figyelmet igénylő állapot és a vörös, ami súlyos működési rendellenességet kifejező, azonnali beavatkozást igénylő állapot. Ha a struktúra alján valamely komponens állapota megváltozik, ez a legfelső szinten lévő szülő objektumig láthatóvá válik, így egészen biztosan nem kerüli el az üzemeltetők figyelmét.

Az Info Worker csomagok telepítése kiegészíti a fenti struktúrát az Office 2007 rendszer és az operációs rendszer bizonyos komponenseinek felügyeletét segítő elemekkel. Így jelennek meg az Office alkalmazások, így az Excel, Word, Outlook stb. alkalmazások teljesítményét figyelő mutatók (általában a memória felhasználás és a processzorterhelés) és az Outlook esetében például a hálózati kapcsolatokat figyelő szabálykészlet. Ez utóbbi segítségével értesülhetünk arról, ha munkatársunk gépe elvesztette a kapcsolatot a postafiókot tartalmazó Exchange kiszolgálóval, illetve mérhetjük azt is, hogy ez az állapot milyen gyakran ismétlődik, és mennyi ideig akadályozza a munkát. A további komponensek megfigyelésével értesülhetünk arról, hogy a Windows Explorer milyen gyakran kényszerül újraindítani saját magát, ami egy lehetséges előjele lehet annak, hogy az adott gép megbízhatósága romlik és esetleg belátható időn belül újratelepítést igényel.

A Windows Client Business Critical nevű felügyeleti csomag telepítése után a felügyeleti csomag részeként már arról is kaphatunk visszajelzéseket, hogy mely gépeken volt sikertelen egyes frissítési csomagok telepítése, milyen szolgáltatások indítása volt sikertelen vagy ezek közül melyik állt le váratlanul. Adatokat gyűjthetünk arról, hogy a kritikus fontosságú megosztások és adatbázis kapcsolatok milyen megbízhatósággal érhetők el, összevethetjük ezeket a hozzájuk tartozó kiszolgáló eseménynaplójával, vagy a közbeeső hálózati eszközök elérhetőségi riportjával.

Mit teszünk a főnökünk asztalára?

Az üzemeltetésért felelős vezetőket természetesen elsősorban nem a gépekről összegyűjtött adatáradat vagy az egyes gépek egyéni állapota érdekli, hanem elsősorban az, hogy milyen színvonalon történik az ügyfelek kiszolgálása, az IT szervezet megfelel-e a rendelkezésre állási elvárásoknak, illetve az, hogy milyen trendekre vagy kockázatokra kell számítani a különböző technológiai területeken a következő időszakban.

A SCOM2007 esetében könnyű dolgunk van a riportok előállítását illetően, mert teljes fegyverzetben rendelkezésünkre áll az SQL Server 2005 Reporting Services valamennyi szolgáltatása. (Nagyobb környezet esetén a SCOM Reporting komponenst erősen ajánlott önálló kiszolgálóra telepíteni). Maguk a riportok pedig a felügyeleti csomagok részeként érkeznek, szorosan kapcsolódnak a csomag többi komponenséhez. Olyannyira integrált a riportkészítési funkció, hogy ki sem kell lépnünk a SCOM felügyeleti konzolról: a Reporting szekción belül szerkeszthetjük és időzíthetjük jelentéseinket tetszés szerint. Az elkészült jelentéseket azután menthetjük Excel táblázatba, további feldolgozáshoz CSV formátumba, képként vagy weblapként is, sőt közvetlenül publikálhatjuk is.

A 10 leggyakoribb hibát összefoglaló heti jelentés

Még kényelmesebb szolgáltatása az új felületnek, hogy az MMC harmadik oszlopában dinamikusan változó eszköztárakat kapunk, attól függően, hogy a konzol melyik részén barangolunk éppen. Ennek megfelelően dinamikusan jelennek meg ebben a szakaszban a rendelkezésre álló riportok is. A kliensek felügyeletéhez kapcsolódóan készíthetünk például jelentést a 10 leggyakrabban bekövetkező alkalmazáshibáról, tetszőleges idő szerinti bontásban (a példán egy hét adatai szerepelnek). A szükséges adatokat akár ügynök nélküli gépekről is megkapjuk, így megfelelően nagy adatforrásunk lehet ahhoz, hogy a jelentésből következtetéseket vonjunk le és döntéseket hozzunk, például egy alkalmazás lecseréléséről vagy a verziófrissítés előrehozásáról.

Az Outlook 2007 rendelkezésre állási jelentése -- a sárgával jelölt időszakokban nem volt a hálózaton elérhető Exchange kiszolgáló

Az üzemeltetők számára hasznosak lehetnek az operációs rendszer, az Office alkalmazások, a Windows Explorer, az Internet Explorer és a Media Player erőforrás felhasználását mutató jelentések. Ezekből visszamenőleg is láthatjuk, hogy milyen összefüggés van például az alkalmazások memória felhasználása és a rendszer válaszidejének növekedése között.

Az ilyen összetett jelentésekből származó információk segíthetik az incidensek okainak feltárását, illetve a problémák megfelelő dokumentálását és átmeneti vagy végleges megoldását. A teljesítményadatokból ezen felül fontos trendeket olvashatunk ki, ami segítségünkre lehet például az egyes komponensek (memória, processzorok, merevlemezek) megbízhatóságának mérésében és így a választott gyártó objektív megítélésében, ami hasznos lehet egy szerződés meghosszabbításáról szóló döntés meghozásakor is, illetve a teljesítményadatok segítenek a géppark cseréjének ütemezésében és az új gépek megfelelő méretezésében is.

A felügyeleti csomagok jelentéseit összehasonlítva azt láthatjuk, hogy míg a korábbi operációs rendszerek (a Windows XP és elődei), az Office és az Info Worker felügyeleti csomagok csak teljesítménymutatókra vonatkozó jelentéseket tartalmaznak, addig a Windows Vista felügyeleti csomagja – a monitorozási funkciók bővülésével arányosan – lényegesen több kész jelentést tartalmaz (az XP 6 riportjához viszonyítva 17-et). A Vista és a SCOM2007 együttműködésében tehát már látható a Microsoft DSI (Dynamic Systems Initiative) irányelv hatása: a Vistát az irányelveknek megfelelően vállalati üzemeltethetőségi, felügyelhetőségi szempontok alapján is tervezték, a SCOM2007-et pedig megjelenése pillanatától alkalmassá tették a Vista részletekbe menő felügyeletére.

A felügyeleti csomagok minőségi megújulását mutató tendencia egészen biztosan folytatódni fog: az egyes Microsoft termékekhez tartozó felügyeleti csomagok időről-időre új verziókban fognak megjelenni. Érdemes tehát gyakrabban visszatérni a Management Pack katalógushoz és figyelni a felügyeleti csomagok verziószámainak változását. A letöltött frissebb csomagokat egyszerűen csak importálni kell és elfogadni, hogy a rendszer felülírja a korábbi verziót.

Somogyi Csaba
IT üzemeltetés szakértő
Microsoft Magyarország