ITL2 - MITágazati mérés: Cloud szolgáltatás jellemzők vizsgálata

A VIK Wikiből
Ugrás a navigációhoz Ugrás a kereséshez
← Vissza az előző oldalra – Informatikai_technológiák_laboratórium_2

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.


2013/14. őszi félév: Cloud szolgáltatás jellemzők vizsgálata

A lap eredeti címe: „https://wiki.sch.bme.hu/index.php?title=ITL2_-_MITágazati_mérés:_Cloud_szolgáltatás_jellemzők_vizsgálata&oldid=192323”