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

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

← 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.