System Center Operations Manager - út egy (remek) termék megértése felé - III. rész - Szolgáltatás-szint mérés

  • Article

Innentol kezdve bevezetek egy jelölést a post címének a végére, mely jelzi, hogy az adott bejegyzésben a két fo terület közül elsodlegesen melyik kerül tárgyalásra, ennek a rendszernek alapján ezen blogbejegyzés a Szolgáltatás-szint mérés gondolatmenetét viszi tovább.

Az elozo postban ott hagytuk abba, miszerint:

"De mi is ez a tranzakció alapú történet? Nem akarok "tippelni" és "jósolni" komponensekbol, hanem az érdekel, hogy a felhasználók most mit éreznek, megy-e nekik amit szeretnének vagy nem. Ha a példaszolgáltatásunk az e-mail, akkor:

  •  "be tud-e lépni a különbözo kliens ezsközökkel a mailboxba elvárt idon belül?"
  •  "tud-e levelet küldeni cégen belül / cégen kívül?"

Ezeket nyilván hitelesen úgy tudjuk megválaszolni, ha MEGPRÓBÁLJUK. Ez egyszerunek hangzik, de nem az. Hogy miért és miben tud itt a SCOM segíteni?"

Hogy miért is nem egyszeru ez? Vegyünk pár kihívást példákon keresztül:

 

Tranzakció hitelessége

Nos, ez a mérjük/próbáljuk meg azt amit a felhasználó csinál/tapasztal a rendszerben nem mindig egyszeru.

Ha egy könnyu esetet veszünk példaképpen, egy weboldalt, mely egy adott cím beírása után bizonyos információkat megjelenít a felhasználó számára itt a tranzakció teljesen hiteles tud lenni - el tudjuk végezni és meg tudjuk mérni egy az egyben a felhasználói muködést. Persze a kivitelezése csak akkor lesz egyszeru is, ha a felügyeleti rendszerünk hordozza ezt a képességet, pl. rendelkezik egy olyan könnyen paraméterezheto wen-motorral, melybe beadjuk a feltételeket és visszaadja az eredményt - jelen esetben az Operations Manager természetesen ilyen :) De ha a tranzakcionális hitelességre kanyarodunk vissza, vegyünk egy másik példát:

Van egy pénzügyi alkalmazás, melynek az egyik kritikus funkciója a havi zárás - mely mellesleg egy elég komplex, sok komponenses folyamat így nem triviális hogy mindig rendben lesz. Jó üzemeltetoként szeretnénk bebiztosítani, hogy észrevegyük még idoben, ha gond van a funkcióval illetve mutathassuk, hogy a pénzügyi szolgáltatás rendelkezésre állási szintje hogyan alakul. Nyilván ennek az elozo analógia szeeint egyszeru a megoldása - hajtsuk végre a muveletet és értékeljük ki, hogy minden rendben volt-e. Nos, ez könnyen belátható hogy nem feltétlen elonyös, pl. órás vagy még surubb rendszerességgel lezárni a pénzügyi hónapot azért, hogy kiderítsük: "ha valaki most zárni szeretett volna, akkor tudott-e volna". Másik klasszikus példa erre a pénzforgalmi területek, ahol elméleti síkon egyszeru is lehetne az utalás ellenorzése: az egyik számlámról 5 percenként átutalok 1 ft-ot a másik számlámra - de ennek lehetnek jogi/szabályozási akadályai.

Na de ilyenkor mit tudunk tenni? Közelítünk vagy lebontunk:

  • Közelítünk: nem pontosan azt tesszük, hanem egy ahhoz lehetoleg mindinkább hasonló, de ismételheto / nem destruktív dolgot: a havi zárás példánál valami olyat, mely ugyanazon modulokat, funkciókat szólítja meg, de nem zárja le ténylegesen a hónapot. Itt nyilvánvaló a kompromisszum: nem pont azt a tranzakciót mérjük, amit akarnánk, tehát ott a mérési hiba lehetosége.
  • Lebontunk: nem tudunk még csak közelítot sem találni, jobb hiján elkezdjük az eredeti folyamat elvégzéséhez szükséges modulokat vizsgálni tranzakciókkal: pl. a weboldal/web service adott metódusa (havi zárás) válaszol-e + az adatbázis szükséges táblái tartalmaznak-e minden adatot és kiolvashatók-e. Itt is kompromisszumot kell kötni, nem mérjük végig az elejéto a végéig a folyamatot, nem "elsodleges" tranzakciókat vizsgálunk, hanem "másodlagos" résztranzakciókat

Remélem a fenti példák jól érzékeltetik ezen aspektus nehézségeit. A tranzakció hitelességét tekintve az Operations Manager sem képes nem destruktív módon lejátszani egy destruktív folyamatot, azonban a megvalósításban nagyon sokat tud segíteni az alábbiak mentén:

  • Sok technológia felügyeleti csomagja (pl. Exchange, Lync) magában hordoz KÉSZ és paraméterezheto szintetikus tranzakciókat (pl. levélmegfordulás, videóhívás) így ezeket nem nekünk kell kifejleszteni
  • Ha nincs technológia specifikus megoldás, képes segíteni mind elsodleges tranzakciók lejátszásában (pl. web alkalmazás / web service, session recorder, stb..) bizonyos típusú web frontend-el rendelkezo szolgáltatásoknál
  • Ha nem tud az elsodleges tranzakcióban segíteni, sok beépített, potenciálisan másodlagos tranzakciók alapját szolgáló megoldás található benne (SQL, port-scan, windows service, stb..)
  • Ha másodlagos tranzakció sincs, keretet biztosít tetszoleges méromegoldás (pl. Powershell, VBScript vagy JavaScript) használatára

 

A mérés helye(i)

Tételezzük fel, hogy megvan a szuper kis tranzakciónk. A következo kérdés: honnan mérjünk? A válasz elsore egyszeru: ahonnan a felhasználó használja. Na de mi van, ha mondjuk a levelezést akarjuk mérni és a "tuti" tranzakciónk egy levélmegfordulásos mérés... Ezt hány felhasználó használja? 20-100-5000? Akkor mérjünk mind az 500 felhasználó gépén? És melyik gépen/eszközön - ha több is van neki? Vagy válasszuk a másik végletet, mérjünk magáról a levelezési szerverrol levélmegfordulást - hiszen ott is kiderül, ha nem megy...

Nyilván itt a produkció az egyensúly megtalálása, a felhasználók felhasználási terület/szokások szerinti csoportosítása, az egypontos hibalehetoségek megtalálása és a folyamat pontos megértése (pl. nem kell minden eszközrol komplett levélmegforsulást mérni, elég az egyikrol és a többirol csak megnézni, hogy elérjük-e a mailboxot - azaz fel tudunk-e levelet adni, mely ettol a ponttól kezdve ugyanazon utat járja be).

Az sem reális, hogy még ha csak egy eszközrol is, de minden felhasználótól mérünk. Nyilván érdemes pl. hálózati kapcsolatok vagy egyéb szempontok alapján tipizálni ezeket és "kollektív" méropontokat lerakni. Esetleg felismerni, hogy ez a folyamat valójában elsosorban a Mailbox kiszolgálókról indul, elég azokat nézni és alternatív módon vizsgálni, hogy azokat elérhetjük-e?

Bármit is választunk, meg kell kötni a kompromisszumot ismét. Hiszen nem mérhetünk minden felhasználó minden eszközérol, hogy per felhasználó legyenek "hiteles" mérési adataink...

Amiben itt az Operations Manager a segítségünkre tud sietni:

  • rugalmas lehetoség újabb méropontok beüzemelésére / kivonására, akár fél- vagy teljes automatizmusok használatával is
  • felülírási rendszer kapcsán esetlegesen méropontonként eltéro határértékek használatával közelíteni a képet

És még egy ráadás téma: mi van akkor, ha "publikus" szolgáltatást akarunk mérni? Azaz valójában a felhasználóink a cégen / biztonsági határainkon túl vannak? Tudok kintrol mérni? A válasz igen, ha Operations Managert használunk, mert az:

  • képes tanusítvány alapú hitelesítés alapon biztonságos kommunikációt folytani olyan gépekre helyezett ügyfél-komponenssel, mely nem tagja a tartománynak/erdonek

 

A mérés gyakorisága

Ha megvan a jó kis tranzakciónk és megvannak a mérési helyek is, akkor jön a következo kérdéskör: milyen gyakran mérjünk? Erre rá lehetne vágni, hogy "mivel nem tudjuk a felhasználó mikor hívja meg a funkciót, minnél gyakrabban mérünk, annál jobb". És ez igaz is. Itt csak bizonyos technológiai / méréstechnikai kötöttségeket kell figyelembe venni:

  • Minden mérés kis-közepes (komplexitás függvényében) terhet ró mind a mérogépre, mind a mért rendszerre. Nem lenne szerencsés, ha azáltal, hogy 3 másodpercenként mérünk azt ugyan tudhatjuk, hogy el tudná-e végezni szinte bármely idopillanatban a felhasználó a muveletet, valójában nem tudja, mert nem jut rá processzorido a sok teszteléstol :)
  • Egy tranzakciónak van átfutási ideje is, pl. levélmegfordulásnál az elvárt "még jó" idohatárt pl.120 másodpercben határozzuk meg. Ebben az esetben a mérésnek meg kell várnia ezen idoszakot, hogy megállapítsa, tényleg nem zajlott-e le a tranzakció az elvárt idoben. Ha viszont egy ilyen mérést percenként ellövunk, egymásra futások lesznek és könnyen belátható, hogy hiába futtatjuk percenként, a kiesést csak két perc elteltével tudjuk majd detektálni

Ok, a fentiek alapján ráér ritkábban is. Itt a következokre kell figyelni:

  • Ha mondjuk valamit csak 15 percenként mérünk, ennyi lesz a mért minimális kiesés is (független attól, hogy a tényleges kiesés esetleg csak 1 percig tartott). Hiszen ha egy mérés kapcsán "rosszba" billenünk, legközelebb csak 15 perc múlva mérünk újra és billenhetünk vissza

Amiben az Operations Manager segíteni tudja a kialakítást

  • rugalmas felülírási szabályrendszerrel akár mérohelyenként külön-külön határértékek beállítása

 

A mérés redundanciája

Ha a fentiekbol mindent jól kitaláltunk, akkor sem dolhetünk még hátra: mi van abban az esetben, ha a mérogépünk meghibásodik vagy újraindításra szorul? Ez egy black-out lenne, ezen idoszak alatt nem tudunk mérni és ezt se "jó" se "rossz" idoszaknak nem lenne jó elszámolni, igazából az lenne a legszerencsésebb, ha nem lenni ilyen idoszak. Na de ez nem lehetséges reálisan, így be kell biztosítanunk magunkat: "mi jobb egy mérogépnél? KÉT mérogép".

Redundancia kialakítására illetve kommunikációs hiba túlélésére több lehetoséget is biztosít az Operations Manager:

  • Minden ügynök alapértelmezetten store-and-forward elven muködik, azaz jelen esetben ha pl. kiesik a hálózati kapcsolat a mérogép és az Operations Manager kiszolgáló között de a mérogép és a ért szolgáltatás között továbbra is van kapcsolat, a mérések folytatódnak, az eredmények tárolódnak majd a kapcsolat felépülése után felküldésre/feldolgozásra kerülnek
  • Egy ügynök komponens több kiszolgálóval is kapcsolatban állhat, automatikusan átáll az egyik kiesése esetén
  • Több mérogép mérési adatait tudjuk különbözo aggregációk kapcsán összefuttatni - kizárni a mérogép kiesések negatív hatásait

 

Rakjuk össze: mérésekbol szolgáltatások

Egy-egy adott szolgáltatás leírásához több mérés is szükséges lehet. Gondoljunk csak bele: ha különbözo felhasználói típusok használják különbözo funkciókon / tranzakciókon keresztül.

Végig kell gondolni az adott szolgáltatás:

  • Interfészeit és azok elérési metódusait
  • Kulcstranzakcióit
  • Felhasználói köreit, kritikus csoportjait, lokációit

Ha azon egyedi mérések megvannak, melyek a fenti esetek egy részt vagy adott részeit fedik, "már csak" össze kell rakni a szolgáltatást.

Vegyünk például egy levelezési szolgátatást és annak mérési absztrakcióját:

  • Mérjük a kliens-elérési protokollokat (MAPI, POP3, IMAP4, Web Access)
  • Mérjük a levélmegfordulást
  • Mérjük a postaláda életképességét

Mit mondunk a levelezési szolgáltatásra ha mondjuk:

  • Minden OK, de nem megy a Web Access?
  • A postaládák 85%-a érheto csak el?
  • A levélmegfordulási ido adott kiemelt levelezési célok felé határértéken túl van, a többi felé nem?

Ezekre a kérdésekre már nem lehet általános választ adni így nem is kísérlem meg - megfelelo konzultáció, forrásadatok (KPI, SLA) mentén határozható meg.

Amit biztos tudunk, az az, hogy az Operations Manager segít a kívánt eredmény elérésében azáltal, hogy:

  • Elemi mérések adott aggregációs relációkba állíthatóak
  • Ebbol fastruktúra építheto
  • A "faágakon" is állíthatóak az aggregációk muködései
  • Grafikus megjelenítési és szerkesztési felületet biztosít ehhez
  • Többféle vizualizációs megoldás segít az eredmény áttekinthetové tételében

 

V