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

A VIK Wikiből
A lap korábbi változatát látod, amilyen Szikszayl (vitalap | szerkesztései) 2014. március 13., 13:49-kor történt szerkesztése után volt.
(eltér) ← Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)
Ugrás a navigációhoz Ugrás a kereséshez
← 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. 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).

"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?

-- don - 2010.11.03.