Autonóm és hibatűrő informatikai rendszerek - Összefoglaló zh-hoz

← Vissza az előző oldalra – Autonóm és hibatűrő informatikai rendszerek

Bevezető

• Cloud comping: public és private cloud.
• Többmagos krízis.
• Fault→Error→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→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)→hibaállapot(error)→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→legnehezebb az emberi hibák modellezése
  • automatikus transzformáció→hiba lemodellezhető
  • komplexitásra figyelni kell: formális módszerek 2^120 méretű állapotteret kezelnek (ipari projektekben: 2^200→~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→következtetés)-
• Predikátum-absztrakció: A program az elágazásaitól lesz bonyolult→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.

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→nem igazi megoldás.
• A fenti problémára egy megoldás: Robusztus particionálás elve: (integrált rendszerek tervezési alapelve):

1. 1. Minden feladatra: [math] \{tipus_{eroforras_{j}}\} \supseteq \{tipus_{feladat_{i,j}}\} [/math]
   2. A Kemény korlátokra [math] kapacitas_{eroforras_{j},tipus} \geq \sum_{i}{kapacitas_{feladat_{i}, tipus}} [/math]
   3. 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).

Szoftverminőség-menedzsment és szoftver-megbízhatóság

FIXME: ez kell, vagy csak kitekintő előadás volt?

-- don - 2010.11.03.