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

← Vissza az előző oldalra – Informatikai_technológiák_laboratórium_2

Segédletek

Felkészülési útmutatók

• Segédlet

Ha ez nem működne akkor:

• szolg_szintek_segedlet_2009_osz.pdf

Feladatsor

• File:ITL2-MITá-TBSM_utmutato_2009-11-17.pdf

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.