ITL2 - MITágazati mérés: Cloud szolgáltatás jellemzők vizsgálata
A VIK Wikiből
2013 előtt: Szolgáltatási szint menedzsment (TBSM)
Segédletek
Felkészülési útmutatók
Ha ez nem működne akkor:
Feladatsor
Ellenőrző kérdések
1. Mik a szolgáltatásbiztonság jellemző attribútumai?
- Rendelkezésre állás (availability): készenlét (helyes) szolgáltatás nyújtására.
- Megbízhatóság (reliability): helyes szolgáltatás nyújtásának folytonossága.
- Biztonságosság (safety): a felhasználók ás környezetük szempontjából katasztrofális hatások hiánya.
- Integritás (integrity): a rendszer helytelen módosulásainak hiánya.
- Karbantarthatóság (maintainability): módosíthatóság és javíthatóság.
2. Oldja fel az SLA rövidítést és adjon a fogalomra rövid definíciót!
- SLA: Service Level Agreement.
- QoS (Quality of Service) mérőszámoknak a definícióját, azok megkötéseit, valamint be nem tartásuk esetén a szankciókat tartalmazza.
- Tipikusan jogi dokumentumok, szolgáltatót kártérítésre kötelezi.
3. Az SLA-k betartásának kötelezettsége milyen hatással van az informatikai infrastruktúrát támogató folyamatokra?
- Az IT folyamatokat is úgy kell kialakítani, hogy megfelelő mértékben biztosított legyen az SLA sértések elkerülése.
4. Mi történik egy üzenettel a Netcool OMNIbus ObjectServeren és miért, ha a Severity mezőjének értéke 0-ra változik meg?
- Severity: alert adatbázis status táblájának egy oszlopa az ObjectServer-ben. Ha értéke 0, az azt jelenti, hogy az adott rekordban tárolt üzenet törölhető.
- Csak akkor törlődik a rendszerből, ha azt valami explicite eltávolítja (pl.: időzített trigger).
5. Mi a különbség a Netcool OMNIbus ObjectServer alerts.status táblájának Severity és Type mezői között? A kettő egyszerre mely beépített mechanizmusban kap szerepet?
- A Severity mező a probléma súlyosságát adja meg (1: nem meghatározott 2: figyelmeztetés ... 5: kritikus)
- a Type mező a riasztás típusát adja meg (0: nem beállított, 1: probléma, 2: probléma megoldása)
- A _generic_clear_ triggerben van együtt szerepük.
6. Sorolja fel az OMNIbus néhány fontosabb univerzális szondáját és mindegyikre adja meg az adatgyűjtés módját!
| Szonda neve | Adatgyűjtés módja |
| Exec Probe | Fork-olt folyamatok stdout-jának értelmezése |
| Fifo Probe | Nevesített pipe-on kapott bemenet értelmezése |
| Generic ODBC Probe | Olvasás adatbázisból |
| Generic Log File Probe | Logállományból olvasás és értelmezés |
| Ping Probe | ICMP kérések elvégzése és kiértékelése |
| SNMP Probe | SNMP lekérdezés |
| Socket Probe | TCP/IP kiszolgáló socket-re kapott ASCII adatok értelmezése |
| Syslog Probe | UNIX rendszerlogok értelmezése |
| Syslogd Probe | Távoli UDP portra logolásra konfigurált syslogd-k üzeneteinek fogadása és értelmezése |
7. Az ObjectServerben milyen trigger típusokat különböztetünk meg? Miért szükséges adatbázis trigger az OMNIBusban? Említsen meg néhány konkrét triggert!
- Triggert ípusok:
- adatbázis (database)
- időzített (temporal)
- jelzés (signal)
- Miért szükséges:
- Az adatbázis műveletek nem atomiak, egyszerre több szondából is érkezhet az adatbázis felé kérés az adatgyűjtés során. Ennek a problémának kezeléséért szükséges adatbázis triggert készíteni.
- Konkrét triggerek:
- generic_clear, delete_clear, expire, deduplication triggerek
8. Az adatbiztonság milyen összetevőkből áll, az összetevőket jellemezze!
- Rendelkezésre állás (availability): készenlét (helyes) szolgáltatás nyújtására.
- Integritás (integrity): a rendszer helytelen módosulásainak hiánya.
- Bizalmasság (confidentiality): jogosulatlan információszerzés hiánya
9. Vázolja fel az alerts.status táblát!
| Oszlopnév | Adattípus | Leírás |
| Identifier | varchar(255) | Egyértelmű eseményazonosító, mely pl. a deduplikációt vezérli |
| Node | varchar(64) | A riasztás forrásaként értelmezhető felügyelt entitás. IP hosztok esetén a hoszt (DNS) neve; amennyiben az nem állapítható meg, úgy az IP cím. |
| Manager | varchar(64) | Az eseményt begyűjtő probe neve; használható a probe-ot futtató hoszt jelzésére is |
| AlertKey | varchar(255) | Az adott node-on belül annak a felügyelt entitásnak a neve, amire a riasztás vonatkozik |
| Severity | integer | Súlyosság érték; meghatározza a riasztás színét az eseménylistában (lásd később). Az értelmezett konstansok: 0: „clear” („törölhető” üzenet) 1: nem meghatározott 2: figyelmeztetés 3: kisebb probléma 4: súlyos probléma 5: kritikus |
| Summary | varchar(255) | A riasztás okának szöveges összefoglalója. |
| StateChange | time | Automatikusan karbantartott időbélyeg ; az adott sor legutolsó beszúrásának vagy frissítésének időpillanata (akármely forrásra) |
| FirstOccurence | time | A riasztás első beszúrása és a UNIX epoch között eltelt idő, másodpercekben |
| LastOccurence | time | Az utolsó időpont amikor a riasztás frissítve lett az őt szolgáltató szondán |
| InternalLast | time | Az utolsó időpont amikor a riasztás frissítve lett az ObjectServer-en |
| !Tally | integer | Az ezen a riasztáson bármely forrásból elvégzett (újra)beszúrások és frissítések száma |
| Acknowledged | integer | 0/1 flag; azt reprezentálja, hogy az eseményt egy operátor már tudomásul vette-e vagy sem |
| ExpireTime | integer | Az esemény törlődjön automatikusan ennyi másodperc után |
| Type | integer | A riasztás típusa (figyelem: ez nem azonos a súlyossággal!). A fontosabb értelmezett konstansok: 0: nem beállított 1: probléma 2: probléma megoldása |
10. Mit takar a "status.alerts" kifejezés az ObjectServer terminológiájába? Mire használják?
- Az ObjectServer "status" adatbázisának az "alerts" táblája.
- A különböző szondákból érkező adatokat ebben a táblában tárolják.
-- dON - 2009.11.24.
-- FaPe - 2009.11.24.
