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

• Media: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.

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

• MIT Ágazati: Felhőalapú szolgáltatások vizsgálata