Mellékleteink: HUP | Gamekapocs
Keres
Ősszel is lesz HWSW free! Alkalmazott AI meetup és agilis fejlesztői meetup a módszertanok dzsungeléből, szeptember 24-25-én.

Kliensfelügyelet Microsoft módra

TechNet, 2007. november 16. 09:34
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

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 főként megbízhatóan üzemeltetni. Cikkünkben néhány érvet szeretnénk felsorolni a kisebbb kliensek, kisvállalati rendszerek monitorozása mellett is.

hirdetés
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! >>>

A cikk több oldalból áll:
Facebook
Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
A HWSW októberben induló gyakorlatorientált, 10 alkalmas, 30 órás online képzéseire most early bird kedvezménnyel lehet regisztrálni!