Autonóm és hibatűrő informatikai rendszerek - Összefoglaló zh-hoz forrásának megtekintése

{{vissza|Autonóm és hibatűrő informatikai rendszerek}}

==Bevezető==
* Cloud comping: public és private cloud.
* Többmagos krízis.
* Fault&rarr;Error&rarr;Failure lánc.
* Self-* technikák: self-configuring, self-healing, self-optimalization, self-protection

==A szolgáltatásbiztonság alapfogalmai==
* Ontológiai ábra: Készlet(Asset)--Sebezhető--Sebezhetőség.
* Ismert veszélyek és futási idejű véletlen hibák.
* Külső támadások: historikus ismeretek; statisztika csak az átlagos hekkerekről.
* Hogyan védjük meg azt, amit nem ismerünk?
** Monitorozás: elkapni a támadót, mielőtt kárt okoz.
** Külső felügyelet, komparálás; ha nagy a kockázat, nagy szemcsézettség (granuralitás)
* Megoldás a virtualizáció: durva granuralitás olcsón&rarr;ez a cloud lényege.

==Hibatűrő rendszerek tervezési mintái==
===Ismétlés===
* Singleton
* Facade
* Observer

===Architektúrális mintanyelv===
* Units of mitigation (kezelési egységek) - Hogyan kerüljük el, hogy hiba esetén az egész rendszer összemoljon?
* Correcting audits (javító auditok) - A hibákat ASAP fel kell fedezni és javítani, a hiba tényét pedig naplózni kell.
* Redundancy (redundancia) - Redundanciával megoldható, hogy hiba esetén a a javítással párhuzamosan is folytatódjon a működés.
* Minimize human intervention (emberi beavatkozás minimalizálása) - A hibajavítás minél jobban automatizált, annál kevesebből lesz hibahatás, és annál kevesebb procedurális hiba alakul ki(?).
* Maximize Human Participation (emberi részvétel maximalizálása) - A megfelelő szakértelemmel rendelekező emberi résztvevőknek megfelelő felületet kell biztosítani (pl.: karbantartási felületet és hibamefigyelőket).
* Maintenance Interface (karbantartási felület) - Karbantartásra elkülönített felületet kell biztosítani. 
* Someone in charge (felelős) - Ha a hibatűrés nem teljesíti a feladatát, akkor mindig egyértelműen lennie kell egy felelősnek, aki meghatározza, hogy mi ilyenkor a teendő.
* Escalation (eszkaláció) - Ha a helyreállítás, vagy a kompenzálás sikertelen, akkor drasztikusabb eszközöket kell bevetni. 

===Detektálási minták===
* Existing metrics (létező metrikák) - A túlterheltséget már létező metrikák alapján érdemes vizsgálni, hogy maga a vizsgálat ne járuljon ahhoz hozzá. Pl.: CPU kihasználtság, memória kihasználtság, kernel puffer mérete, stb.
* Routine manintenance (rutin karbantartás) - kivédhető hibák ellen érdemes rutinszerű, megelőző karbantartásokat végrehajtani. 
* Routine exercises (rutinszerű gyakorlatok) - A hibatűrő komponenseket meg kell dolgozni akkor is, ha nincs hiba, ezzel is biztosítva, hogy ha egy hibahelyzet kialakul, a rendszer az elvárt módon fog reagálni.
*  Routine audit (rutinszerű audit) - Az adatok konzisztenciájának ellenőrzése (i) párhuzamosan a munkával (ii) munka helyett (pl:chkdisk). Audit minták: checksum.
* Fenomenologikus rendezés - a hibákat nem a belső helyzet, hanem a hatás alapján csoportosítjuk (FIXME: ez minta?).
* Heartbeat - (i) a monitorozott küld életjelet (ii) a monitor küld kérést (ping, vagy dummy request).
* Acknowledgement - TCP ACK üzenet, vagy http 200.
* Watchdog - Egy komponens ellenőrzi a többi diagnosztikai állapotát (pl.: ha nincs üzenetküldés-, vagy feldolgozás). Ha az állapot eltér az elvárttól, akkor be kell avatkozni.
* Realistic treshold - meddig kell várni az ACK üzenetre? Ha sokáig várunk, a hiba szétterjed, de ha túl gyorsan reagálunk, akkor sok lesz a fals-pozitív eredmény. Kétféle késleltetést kell figyelembe venni: (i) üzenetküldési késleltetést, (ii) detekciós késleltetést. Ökölszabály: keressük a worst-case körbefordulásra vonatkozó detekciós késleltetést, és ennek az egész számú többszörösének választjuk (a szorzó a prioritástól függ).
* Voting (szavazás)
* Teljes paraméter ellenőrzés: minden hívás paraméterkészletét ellenőrizzük. 
* Tranziensek kivárása: leaky bucket mintával. Pl.: A processzor kihasználtsága nem baj, ha rövid ideig 100%os, de utána már problémát okoz. 

 
===Helyreállítási minták===
* Quarantine (karantén, hibabehatárolási tartomány) - 
* Failover (feladatátvétel, átkapcsolás)
* Restart
* Limit retries
* Return to reference point
* Rollback
* Roll-forward
* Checkpoint
* What to save
* Remote storage
* Individuals decide timing
* Data reset
* Error handler
* Concentrated recovery

Ezek a minták csak a könyvtári jegyzetben szerepelnek
* '''Let the sleeping dog lie''' - Érdemes-e megjavítani a hibát, vagy inkább csak vegyük tudomásul a létét.
* '''Reintegration''' - Passziváljuk a hibát, és csak utána helyezzük üzembe a szolgáltatást. 
* '''Reproducible error''' - Monitorozzuk a hibát, miközben aktiváljuk.
* '''Small patches''' - Javítsuk a hibás programkódot.
* '''Root cause analysis''' - Mindig a kiinduló hibát próbáljuk javítani. 
* '''Revise procedure''' - Vizsgáljuk meg, hogy ki és hogyan vett részt a hiba kialakulásában, és próbáljuk meg javítani ezt a folyamatot. 

==Formális hibamodellezés==
* Specifikáció és implementáció: a specifikáció készítésekor nem tudjuk, hogy milyen hibára kell felkészülni.
* Halmazábra: Konkrét hibahalmaz, generált hibahalmaz, nem garantáltan fedett hibák halmaza, nem előforduló hibák (ha nagy, nem vagyunk hibatűrőek; felesleges költség, kivéve ha összességében olcsó).
* Robosztusság def.: nem tervezett hibák tűrése.
* Valósághűség: ethernet kábel hibájának modellezési példája. Fizikai hibák modellezhetőek nagyszámú korrelált logikai hibával(?)
* Hibamodell: egységesen kell kezelni a hibaok(fault)&rarr;hibaállapot(error)&rarr;hibahatás(failure) hármast.
* Kiindulás:
** Proof of correctness: hibátlan modell helyességének bizonyítása. 
** Dependability  analysis: lehet-e ugyanilyen helyességbizonyítást csinálni, ha nem működik minden jól?
* Metodika következménye:
** tartalmazza a technológiai tudást&rarr;legnehezebb az emberi hibák modellezése
** automatikus transzformáció&rarr;hiba lemodellezhető
** komplexitásra figyelni kell: formális módszerek 2^120 méretű állapotteret kezelnek (ipari projektekben: 2^200&rarr;~40bit: kicsi)
** jó megközelítés: (i) no loss of critical cases (ii) minimize false alarms.  
* Qualitative reasoning: hiba térbeli időbeli értékeiből is lehet következtetni és tartományokat kijelölni. (görbe: shape, peak&rarr;következtetés)-
* Predikátum-absztrakció: A program az elágazásaitól lesz bonyolult&rarr;a feltételek mentén 2-2 részre lehet vágni az értéktartományokat. (FIXME:példa)
* Hibasorozat feldolgozása temporális logikával.

==Hibamodellezés,a PMC modell (Gyakorlat)==
* 1. ábra: bemenetek+kimenetek+fault activation bemenetek(melyik hibát aktiváljuk).
* 2. ábra: hibakategóriák + eltérés automata formalizmusa.
* Véges automata problémája az állapottér robbanás. Tér-, és időbeli absztrakció. 
* Trükk: kategorizáljuk a bemeneti sorozatokat (ezek a szindrómák).
* 3. ábra: szindróma definíciójához blokkdiagram.
* 4. ábra: Egy A komponens definiálható R_{A} relációval; plusz egy másik B komponens bemeneteként az A egy kimenete szolgál.(FIXME: ez nem világos, hogy van pontosan)
* Példa: három rétegű architektúra. Szindrómák rendszerszintű leírásához: L_e={OK, OMISSION, FORMAT, DATA, ERROR_CODE}.
		 * Attól függően, hogy mit akarok megtudni az I/O sorozatról, aszerint adódnak a szindrómák.
*** Legsúlyosabb hiba: biztonságkritikus rendszerekben ez fontos lehet.
		  * Állandósult hibamódok.
		  * stb.
** Feltételezés: minden szindrómát ugyanazon a nyelven fogalmazunk meg
*** S_0
		  * minden x-re: S_x = FG x
		  * overabstraction: inkább fals pozitív elemeket is vegyünk be, mintsem hogy egy hibát kihagyjunk.
** FIXME: R'-s képlet a jegyzetben + BDD.
* Diagnosztika: fault detection + fault localization = fault diagnosis.
** általános eset: FRU (Field Replaceable Unit) szintig vizsgáljuk a rendszert. 
** elosztott eset: elosztott rendszerek alapszolgáltatásai szintig vizsgáljuk a rendszert. 
* 1967: Preparata, Metze, Chien: PMC modell:
** A rendszer n darab komponensből áll{u_1, u_2, ... u_n}.
** Minden elem vagy hibás(1), vagy hibátlan(0). 
** Permanens hibákat feltételezünk.
** A komponensek egymást ellenőrzik, magukat nem. 
** Egy központi egység gyűjti a teszteredményeket és diagnosztizál.

{| border="1"
| '''n_1 - tesztelő''' || '''n_2 - tesztelt''' || '''Kimenet''' 
|-
|  0  ||  0  ||  0  
|-
|  0  ||  1  ||  1  
|-
|  1  ||  0  ||  x  
|-
|  1  ||  1  ||  x  
|}
** Az eredmények összessége egy szindrómát alkot. 
** 5. ábra: körkörös diagnosztizáló gráf: 1-diagnosztizálható, mert legfeljebb 1 hibát derít fel.
*** '''Def.:''' Egy N elemű rendszer 1 lépésben t-diagnosztizálható, ha minden hibás elem lokalizálható csere nélkül (és <= t  hiba van a rendszerben).
*** '''Tétel:'''  Ha az N elemű rendszer rendszer t-diagnosztizálható, akkor: 
**** 2t+1 <= N, és 
**** minden elemet legalább t elem tesztel. 
** A konstrukció nem adja meg a diagnosztizálhatóság mikéntjét.
** Kiterjesztés - BGM modell: a táblázatban (1,1,x) helyett (1,1,1) lesz. Erre a modellre az N elemű t-diagnosztizálható rendszer esetén az N >= t+2 összefüggés igaz.
 
==Szolgáltatásbiztonsági benchmarkok==
* Cél: Teljesítmény-összehasonlítás a döntéstámogatáshoz (mit érdemes venni) és a teszteléshez (kell, vagy lehet-e javítani).
*  Benchmark környezet Specifikációja (hw, sw, context, maintenance, schedule, doc) és alapelvei (kölcsönös zavarás, 80/20-as szabály, mit mérünk, reprezentatív minta),
* Terhelés típusai: (i) number crunching (ii) OLTP (iii) Batch (iv) DSS.
* Metrikák: Futási idő, tranzakciósebesség, áteresztőképesség, $/tx, válaszidő, X-percentil (egy adott halmaz X%-a ez alatt az érték alatt van)
* Eredmények összehasonlítása: referencia-rendszerhez, ami absztrakt benchmarkból is jöhet.
* Problémák: kis problémaméret, releváns-e az eredmény, elavulnak a referenciák, nem biztos hogy minden rejtett paramétert figyelembe veszünk, lehet hogy a specifikációnk is hiányos, ami alapján a tesztet készítettük.
* Benchmarkok típusai: Mikro, Makro, Nano.
* Eredmények (analitikus) felhasználása: következtethetünk a jövőbeni terhelés eredményére.
* SPEC benchmarkok: SPEC CPU2006, SPECweb2009, !SPECjAppServer2004, !SPECjbm2008 (ingyenes),  SPECvirt_sc2010 (hány virtuális gépig nőnek a metrikák), 
* TPC (Transaction Processing Council) benchmarkok: OLTP rendszerek mérőszámaival dolgozik. TPC-c: e-kereskedelem benchmark. TPC-W: web e-commerce. TPC-app: appserver+webserver egyben. Metrika: SIPS (Web service interaction per second), SIRT (Web service interaction response time).
	
* Autonomic Computing Benchmark
** Rugalmasság (resilience) mérése.
*** Self-* mérése hibainjektálása.
** Elvben tetszőleges architektúrán megvalósítható (!SPECSjAppServer2004-en pl van).
* Metrikái:
** Áteresztőképességi index: P_t/P_a (P_terhelt/P_alap) . 
** Zavar hatása az áteresztőképességre.	
** Fejlettségi index: 3 kérdés 0-8 ponttal osztályozva, majd átlag és normalizálás. Végeredmény 0: nincs automatizmus, 1: nem kell emberi beavatkozás. Skálája nemlineáris, a pontokat egy lista alapján kapja a SUT.
** Emberi interakciók mennyisége (detektálás, analízis, helyreállítás során). 
* Autonomic Computing Benchmark mechanizmusa (ábra): betöltés--hibainjektálás--detektálás--javítás, újraindítás--keep-time--integritás teszt (volt-e degradáció).
* hibafajták: váratlan leállás (hw, os, sw), erőforrás versenyhelyzet, adatvesztés, rush, sikertelen restart det.
* Problémák: zavarok megtervezése és összegyűjtése, szimuláció, eredmények összehasonlítása, terhelés, skálázódás, $$$ár.

==Integrált, szolgáltatásbiztos, valósidejű beágyazott rendszerek optimalizáció alapú tervezése (Esettanulmány)==
* 1. ábra: feladat-erőforrás-kapacitás.
* Két feltétel: (i) A feladthoz szükséges erőforrások rendelkezésre kell, hogy álljanak (ii) Az összes erőforrástípusból legalább annyi kapacitás kell, mint amennyit a feladat igényel. 
* Formalizálás: UML MARTE.
* Statikus erőforrás-hozzárendelés: erőforrásnak léteznie kell, és a csúcsterheléshez tartotó kapacitással kell rendelkeznie. (FIXME: ezt formalizálva megadni). Ha ennek a feltételnek a sérülése esetén funkcionális kimaradást okoz, akkor is így kell számolni (FIXME: kézzel foghatóbban megfogalmazni). Hard RT rendszerben ez a számolás jó, de Soft RT esetén erős túlméretezés (plusz lehet vegyes feladat, ahol Hard RT és Soft RT feladatok is megjelennek: Fékrendszer és cd lejátszó este).
* Dinamikus erőforrás-hozzárendelés: (2. ábra - erőforrás menedzser). Az erőforrás menedzser időkorláttal szuboptimálisan szétosztja a feladatokat a rendelkezésre álló erőforrásokon. 
* Virtualizáció: ha több erőforrásunk van, mint szükséges, akkor a migrációt kihasználva minimális számú gépet használunk, a többit pedig kikapcsoljuk. 
* Probléma: Ha egy erőforráson nem egy dedikált feladat fut (federált rendszerek), akkor integrált rendszerről van szó, akkor az egyes komponensek meghibásodása az erőforrásokon keresztül továbbterjedhet a többire (pl.: problémás ha a CD lejátszó hibája miatt nem fog a fék). (3. ábra). Ez ellen egyfajta védelem, ha az erőforráson csomagolókat helyezünk el (4. ábra: wrapper).
* Diverzitás alapú tervezés: ha van elég erőforrásom, akkor a kritikus alkalmazásokat több példányban futtatom (moduláris.. FIXME: ez mi?).
* Ha két párhuzamos komponens fut a rendszerben, akkor a rendelkezésreállás 0.99-ről 0.9999-re megy fel elvben, de: sw hiba korrelált, valamint hardber hiba esetén common mode error-ról beszélhetünk&rarr;nem igazi megoldás. 
* A fenti problémára egy megoldás: '''Robusztus particionálás elve:''' (integrált rendszerek tervezési alapelve): 
## Minden feladatra: <math> \{tipus_{eroforras_{j}}\} \supseteq \{tipus_{feladat_{i,j}}\} </math>
## A Kemény korlátokra <math> kapacitas_{eroforras_{j},tipus} \geq \sum_{i}{kapacitas_{feladat_{i}, tipus}} </math>
## Ha az erőforrás hibák valószínűsége <math> \neq </math> 0, akkor nem lehet azonos kópián két kritikus feladat.
* 5. ábra: példa hozzárendelés. + példa: ha intenzív adatkommunikáció van (érdemes 1 gépre rakni)
* 6. ábra: már IP feladattá vált.
* Fontos kérdés: ha sok kapacitásunk van, hogyan osszuk el a feladatokat? Az attól függ, hogy milyen új feladatokra számítunk (7. ábra).

=="Szonda" (end-to-end probe) alapú hibadetektálás és diagnosztika==
==Szoftverminőség-menedzsment és szoftver-megbízhatóság==
FIXME: ez kell, vagy csak kitekintő előadás volt?

-- [[CsDonat|don]] - 2010.11.03.

[[Kategória:Mérnök informatikus MSc]]