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

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.

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: $\{tipus_{eroforras_{j}}\}\supseteq \{tipus_{feladat_{i,j}}\}$
   2. A Kemény korlátokra $kapacitas_{eroforras_{j},tipus}\geq \sum _{i}{kapacitas_{feladat_{i},tipus}}$
   3. Ha az erőforrás hibák valószínűsége $\neq$ 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.