Rendszermodellezés. Hibamodellezés (dr. Majzik István és Micskei Zoltán fóliái alapján) Fault Tolerant Systems Research Group

Hasonló dokumentumok
A szolgáltatásbiztonság alapfogalmai

A szolgáltatásbiztonság alapfogalmai

A szolgáltatásbiztonság alapfogalmai

Biztonságkritikus rendszerek architektúrája (2. rész)

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Teljesítménymodellezés

Szoftver architektúra tervek ellenőrzése

Megbízhatósági analízis

Autóipari beágyazott rendszerek. Kockázatelemzés

Biztonságkritikus rendszerek

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Veszély analízis. Rendszertervezés és -integráció előadás dr. Majzik István

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Teljesítménymodellezés

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Biztosítóberendezések biztonságának értékelése

Szoftverminőségbiztosítás

Szolgáltatásbiztonság verifikációja: Megbízhatósági analízis

A fejlesztési szabványok szerepe a szoftverellenőrzésben

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

Biztonságkritikus rendszerek Gyakorlat: Megbízhatósági analízis

Architektúra tervezési példák: Architektúrák biztonságkritikus rendszerekben

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Kedvenc rejtvényeim Mit tudok és mit hiszek el?

Veszély analízis. Rendszertervezés és -integráció előadás dr. Majzik István

Rendszermodellezés. Modellellenőrzés. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Szolgáltatásbiztos rendszerek: Architektúra tervezési példák

Szoftverminőségbiztosítás

Számítógép-rendszerek fontos jellemzői (Hardver és Szoftver):

Hálózatba kapcsolt adatbázisok. Erős Levente, TMIT 2011.

Biztonsági folyamatirányító. rendszerek szoftvere

Felhők teljesítményelemzése felhő alapokon

Virtualizált környezetek teljesítménymérése és elemzése

Biztonságkritikus rendszerek architektúrája

Teljesítménymodellezés

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

A szolgáltatásbiztonság analízise

Fejlesztés kockázati alapokon 2.

Szoftverminőségbiztosítás

Bevezetés. Adatvédelmi célok

Az Invitel adatközponti virtualizációja IBM alapokon

A BIZTONSÁGINTEGRITÁS ÉS A BIZTONSÁGORIENTÁLT ALKALMAZÁSI FELTÉTELEK TELJESÍTÉSE A VASÚTI BIZTOSÍTÓBERENDEZÉSEK TERVEZÉSE ÉS LÉTREHOZÁSA SORÁN

Szoftver-mérés. Szoftver metrikák. Szoftver mérés

Verifikáció és validáció Általános bevezető

Windows Server 2012: a felhő OS

Utolsó módosítás:

A kockázatelemzés menete

Budapest Sysadmin Meetup Failover Cluster 1x1. Gál Tamás. Cloud Infrastructure TSP Microsoft Magyarország

Kritikus Beágyazott Rendszerek

Biztonságkritikus rendszerek Gyakorlat: Architektúrák

Rendszermodellezés: házi feladat bemutatás

Mosolygó Ferenc értékesítési konzultáns

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása

Szoftverminőségbiztosítás

Sztochasztikus temporális logikák

A hibakezelés tesztelése: Hibainjektálás

Szimuláció. Fault Tolerant Systems Research Group. Budapest University of Technology and Economics. Department of Measurement and Information Systems

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

Beágyazott információs rendszerek

Hálózati szolgáltatások biztosításának felügyeleti elemei

Közlekedési automatika Biztonsági architektúrák

TANMENET 2018/2019. tanév

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

TERMÉKEK MŐSZAKI TERVEZÉSE Megbízhatóságra, élettartamra tervezés I.

SZOLGÁLTATÁS BIZTOSÍTÁS

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Új kompakt X20 vezérlő integrált I/O pontokkal

Valós idejű kiberfizikai rendszerek 5G infrastruktúrában

Teljesítménymodellezés

A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK

Üzleti kritikus alkalmazások Novell Open Enterprise Serveren

1002D STRUKTÚRÁJÚ, KRITIKUS ÜZEMBIZTONSÁGÚ RENDSZER (SCS 1 ) ELEMZÉSE DISZKRÉT-DISZKRÉT MARKOV MODELLEL

Autóipari beágyazott rendszerek. Integrált és szétcsatolt rendszerek

SZOFTVER-MINŐSÉGBIZTOSÍTÁS BIZTONSÁGKRITIKUS RENDSZEREK. Széchenyi István Egyetem. Alapfogalmak

Modellezés Petri hálókkal. dr. Bartha Tamás dr. Majzik István dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék

Ellátási lánc optimalizálás P-gráf módszertan alkalmazásával mennyiségi és min ségi paraméterek gyelembevételével

Simon Balázs Dr. Goldschmidt Balázs Dr. Kondorosi Károly. BME, Irányítástechnika és Informatika Tanszék

INFORMATIKA EGYRE NAGYOBB SZEREPE A KÖNYVELÉSBEN

Tisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján.

Járműinformatika A járműinformatikai fejlesztés

Valószínűségi modellellenőrzés Markov döntési folyamatokkal

KÖFOP VEKOP A jó kormányzást megalapozó közszolgálat-fejlesztés

Szolgáltat. gfelügyeleti gyeleti rendszer fejlesztése. NETWORKSHOP 2010 Sándor Tamás

Architektúra tervek ellenőrzése

Mérnök informatikus (BSc) alapszak levelező tagozat (BIL) / BSc in Engineering Information Technology (Part Time)

A virtualizáció a modern vállalati informatikai infrastruktúra alapja

Megbízhatóság az informatikai rendszerekben

Tesztelési szintek Tesztautomatizálás

Az előadásdiák gyors összevágása, hogy legyen valami segítség:

biztonságkritikus rendszerek

Szoftverminőségbiztosítás

Optimalizáció ESX-től View-ig. Pintér Kornél ügyfélszolgála3 mérnök

Információ menedzsment

Szolgáltatás mérés/riportolás magas fokon Egy valós megoldás Pepsi berkekben

Mintapélda: Rendszertesztelés a SAFEDMI projektben

Mikor és hogyan érdemes virtualizálni?

Melyek a Windows Server 2008 R2 tiszta telepítésének (Clean Install) legfontosabb lépései?

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Átírás:

Rendszermodellezés Hibamodellezés (dr. Majzik István és Micskei Zoltán fóliái alapján) Budapest University of Technology and Economics Fault Tolerant Systems Research Group Budapest University of Technology and Economics Department of Measurement and Information Systems 1

Tartalomjegyzék A szolgáltatásbiztonság fogalma A szolgáltatásbiztonságot befolyásoló tényezők A szolgáltatásbiztonság eszközei Szolgáltatásbiztonság analízise 2

SIL Motiváció: Hibamentes működés Szolgáltatási szint szerződések (SLA): o Ügyfél által elvárt jellemzők o Telekom szolgáltatások rendszerei ( carrier grade ): Öt kilences : 99,999% (5 perc/év kiesés) Biztonságkritikus rendszerek: o Szabvány előírások a hibák gyakoriságára o Biztonságintegritási szintek (Safety Integrity Level) Biztonságkritikus funkció hibája / óra 1 10-6 THR < 10-5 Hiba nélküli működés ~ 11.000 év?? 2 10-7 THR < 10-6 3 10-8 THR < 10-7 4 10-9 THR < 10-8 3 Ha 15 év az élettartam, akkor ez alatt kb. 750 berendezésből 1-ben lesz hiba

Elkerülhetetlen: Hibahatások Fejlesztési folyamat Működő termék Tervezési hibák Implementációs hibák Hardver hibák Konfigurációs hibák Kezelői hibák 4

Elkerülhetetlen: Hibahatások Fejlesztési folyamat Működő termék Tervezési hibák Implementációs hibák 5 Hardver hibák Konfigurációs hibák Kezelői hibák Fejlesztési folyamat jellemzői: Jobb minőségbiztosítás, jobb módszertanok De növekvő bonyolultság, nehezebb ellenőrzés Szokásos becsült értékek 1000 kódsorra: Jó kézi fejlesztés és tesztelés: <10 hiba marad Automatizált fejlesztés: ~1-2 hiba marad Formális módszerek használata: <1 hiba marad

Elkerülhetetlen: Hibahatások Fejlesztési folyamat Működő termék Tervezési hibák Implementációs hibák 6 Hardver hibák Konfigurációs hibák Kezelői hibák Technológia korlátai: Jobb paraméterek, jobb anyagok De növekvő bonyolultság (érzékenység) Szokásos becsült értékek: CPU: 10-5 10-6 hiba/óra RAM: 10-4 10-5 hiba/óra LCD: ~ 2 3 év élettartam

Elkerülhetetlen: Hibahatások Fejlesztési folyamat Működő termék Tervezési hibák Implementációs hibák Hardver hibák Konfigurációs hibák Kezelői hibák Verifikáció és validáció a tervezés során Hibatűrés működés közben 7

Szolgáltatásbiztonság Szolgáltatásbiztonság (dependability): a képesség, hogy igazoltan bízni lehet a szolgáltatásban o igazoltan: elemzésen, méréseken alapul o bizalom: szolgáltatás az igényeket kielégíti (nemfunkcionális követelmény) 8

Szolgáltatásbiztonság jellemzői Katasztrofális következmények nélküli szolgáltatás Szolgáltatásbiztonság Rendelkezésreállás Megbízhatóság Biztonságosság Bizalmasság Integritás Karbantarthatóság Javítás és módosítás lehetősége Bármikor kész szolgáltatás Folytonosan hibamentes szolgáltatás (Adat)Biztonság Nincs jogosulatlan hozzáférés Nincs hibás változtatás Laprie et. al.: Basic Concepts and Taxonomy of Dependable and Secure Computing 9

Állapotpartícionálás S: a rendszer teljes állapottere UP Hibamentes Healthy DOWN Hibás Faulty 10

Megbízhatósági mértékek Állapotparticionálás s(t) rendszerállapot o Hibás (D) - Hibamentes (U) állapotpartíció U s(t) D u 1 d 1 u 2 d 2 u 3 d 3 u 4 d 4 u 5 d 5... Várható értékek: o Első hiba bekövetkezése: MTFF = E{u 1 } (mean time to first failure, néha MTTF) o Hibamentes működési idő: MUT = E{u i } o Hibás állapot ideje: MDT = E{d i } o Hibák közötti idő: MTBF = MUT + MDT (mean time between failures) t 11

Valószínűség időfüggvények megbízhatóság: (reliability) r(t) = P{ t < t: s(t ) U} (nem hibásodhat meg) rendelkezésre állás: (availability) a(t) = P{ s(t) U } (közben meghibásodhat) o készenléti tényező: K = lim t a(t) = MUT MUT MDT 1.0 a(t) K 0 r(t) t 12

Megbízhatóság megbízhatóság: r(t) = P{ s(t ) U, t < t } (első) meghibásodások gyakorisága: -r (t) o Ez az első meghibásodás ideje valószínűségi változó eloszlásának sűrűségfüggvénye! o Várható érték: MTTF meghibásodási ráta: λ(t) = -r (t) / r(t) (meghibásodás valószínűsége időegységenként és darabonként) o kádgörbe : λ(t) 0 tesztidőszak kezdeti hibák állandósult, üzemszerű működés elöregedés t 13

Megbízhatóság Közelítés: állandósult állapot, λ(t) = λ (konst.) o Örökifjú / memoryless tulajdonság o Jól tesztelt informatikai rendszerre igaz lehet: előbb avul el, minthogy elöregedne Következmény: r( t) -r (t): meghibásodás ideje exponenciális eloszlás lesz o λ paraméterrel o 1/λ várható értékkel o Vagyis: MTTF = 1/λ! e t 14

Rendelkezésre állás követelményei Elosztott rendszerek (hibatűrés nélkül, irányadó számok): 1 szgép: 95% 2 szgép: 90% 5 szgép: 77% 10 szgép: 60% 15

Tartalomjegyzék A szolgáltatásbiztonság fogalma A szolgáltatásbiztonságot befolyásoló tényezők A szolgáltatásbiztonság eszközei Szolgáltatásbiztonság analízise 16

Befolyásoló tényezők Hibajelenség (failure): A specifikációnak nem megfelelő szolgáltatás o értékbeli / időzítésbeli, katasztrofális / jóindulatú Hiba (error): Hibajelenséghez vezető rendszerállapot o lappangó detektált Meghibásodás (fault): A hiba feltételezett oka o hatás: alvó aktív o fajta: véletlen vagy szándékos, időleges vagy állandósult o eredet: fizikai/emberi, belső/külső, tervezési/működési 17

Szoftver hibák Szoftver hiba: Állandósult, tervezési hiba Aktiválás a működési profil függvénye o Bemeneti tartományok, trajektória Megbízhatóság arányos: Tesztelés után bennmaradó hibák száma Bennmaradó hibák száma arányos: Időegység alatt detektált hibák száma a tesztelés végén o Statisztikai tesztelés: Megbízhatóság mérése Statisztikai módszerekkel becsülhető, meddig kell a tesztelést folytatni adott megbízhatóság eléréséhez 18

Hatáslánc Meghibásodás Hiba Hibajelenség o pl. szoftver: meghibásodás: hiba: hibajelenség: o pl. hardver: meghibásodás: hiba: hibajelenség: progr. hiba: csökkentés helyett növel vezérlés ráfut, változó értéke hibás lesz számítás végeredménye rossz kozmikus sugárzás egy bitet átbillent hibás pozícióérték a memóriában robotkar a falnak ütközik Rendszer hierarchiaszint függvénye o alsó szintű hibajelenség felsőbb szinten meghibásodás kimenet beragadás egy chip szintjén hibajelenség rendszer szintjén meghibásodás (chip a cserélhető komponens) 19

Hatáslánc A hatáslánc befolyásolása o meghibásodási tényező csökkentése jobb minőségű komponensek szigorúbb fejlesztési folyamat (ellenőrzés, tesztelés) A meghibásodás-mentesség nem garantálható (csökkenő chipméretek, bonyolultabb programok) o hibajelenség kialakulásának megakadályozása rendszerstruktúra kialakítása: redundancia Hibatípusok: o előre figyelembe vehető hibák: optimális kezelés a tervezési folyamat során o előre figyelembe nem vehető hibák: megfelelő rendszerstruktúra kialakítása szükséges 20

Példa: folyamat Gábor Urbanics László Gönczy Balázs Urbán János Hartwig Imre Kocsis: Combined error propagation analysis and runtime event detection in process driven systems. In Software Engineering for Resilient Systems. 2014, Springer, 169 183. p. Legend Activity Resource Execution Path Dependency Client Pay to $ Business Processes Layer Form processing Money takeover Record transaction Client checked earlier? Y Y Large transaction? N N Perform full check Timeout Manual laundering check Laundering suspected? N Y Receipt Flag & report Customer & Account Identification AppServ1 AppServ2 Supporting Applications Layer DB Cashier Module AppServ3 VM Compliance DB AppServ4 DB1 DB2 Single Hypervisor Physical Resources Layer Backend Server 1 Backend Server 2 Application Server cluster Blade Server Backend Server 3 21

Egyszeres (fizikai) hiba Legend Activity Resource Execution Path Dependency 1 Use Case Id Resource Setup Identifier Failure Mode Outage Client Pay to $ Business Processes Layer Form processing Money takeover 1 Record transaction Stuck Client checked earlier? Y Y Large transaction? N N Perform full check Timeout Manual laundering check Laundering suspected? N Y 1 Receipt Stuck Flag & report Customer & Account Identification AppServ1 AppServ2 Supporting Applications Layer 1 Outage DB Cashier Module AppServ3 VM 1 Outage Compliance DB AppServ4 DB1 DB2 Single Hypervisor 1 Outage Physical Resources Layer 1 Single Fault Backend Server 1 Backend Server 2 Application Server cluster Blade Server Backend Server 3 22

Egyszeres hiba hatása Legend Activity Resource Execution Path Dependency 1 Use Case Id Resource Setup Identifier Failure Mode Outage 2 2 Delayed Delay-incurred Cost Client Pay to $ Business Processes Layer Form processing Money takeover 2 Record transaction Delayed Client checked earlier? Y Y Large transaction? N N Perform full check Timeout 2 Manual laundering check Delay-incurred Cost Laundering suspected? N Y Receipt Flag & report Customer & Account Identification AppServ1 AppServ2 Supporting Applications Layer 2 Degraded DB Cashier Module AppServ3 VM 2 Degraded Compliance DB AppServ4 DB1 DB2 2 Failover Virtualized HA Cluster Physical Resources Layer 2 Single Fault Backend Server 1 Backend Server 2 Application Server cluster Blade Server Farm Backend Server 3 23

Hiba továbbterjedése Legend Activity Resource Execution Path Dependency 1 Use Case Id Resource Setup Identifier Failure Mode Outage Client Pay to $ Business Processes Layer Form processing Money takeover 3 SQLInjected Record transaction Client checked earlier? Y Y Large transaction? N N Perform full check Timeout Manual laundering check Laundering suspected? N Y 3 SQLInjected Receipt Flag & report Customer & Account Identification AppServ1 AppServ2 DB1 DB2 Supporting Applications Layer 3 OK DB Cashier Module AppServ3 VM 3 SQLInjected Compliance DB AppServ4 Virtualized HA Cluster 3 OK Physical Resources Layer 3 OK Backend Server 1 Backend Server 2 Application Server cluster Blade Server Farm Backend Server 3 24

Meghibásodások kategorizálása Hardverhibák o alaprendszer (alaplap, processzor, memória) o tápellátás (tápegység, szünetmentes táp) o adattároló alrendszer o hálózat Szoftverhibák o az operációs rendszer hibái o alkalmazáshibák o illesztőprogram-hibák Emberi hibák o rendszergazdai hibák o illetékes felhasználók nem rosszindulatú hibái o illetékes felhasználók rosszindulatú hibái o illetéktelen felhasználók támadásai Környezeti hatások o üzemeltetési környezet rendellenességei, például a légkondicionálás leállása, bombariadó, csőtörés o természeti katasztrófák 25

A hibajelenségek okai IT rendszerek esetén 26

Tartalomjegyzék A szolgáltatásbiztonság fogalma A szolgáltatásbiztonságot befolyásoló tényezők A szolgáltatásbiztonság eszközei Szolgáltatásbiztonság analízise 27

A szolgáltatásbiztonság eszközei Hiba megelőzés: Meghibásodás megakadályozása o fizikai hibák: jó minőségű alkatrészek, árnyékolás,... o tervezési hibák: verifikáció Hiba megszüntetés: Hibaállapotból kimozdítás o prototípus fázis: tesztelés, diagnosztika, javítás o működés közben: monitorozás, javítás Hibatűrés: Szolgáltatást nyújtani hiba esetén is o működés közben: hibakezelés, redundancia Hiba előrejelzés: Hibák és hatásuk becslése o mérés és jóslás, megelőző karbantartás 28

Hibatűrő rendszerek Akármilyen jó is az ellenőrzés a tervezés során, a szolgáltatásbiztonság nem garantálható: o időleges hardver hibák (ld. zavarérzékenység) o teszteletlen szoftver hibák o figyelembe nem vett komplex interakciók Fel kell készülni a működés közbeni hibákra! Hibatűrés: Szolgáltatást nyújtani hiba esetén is o működés közbeni autonóm hibakezelés o beavatkozás a meghibásodás hibajelenség láncba o rendszertechnikai megoldások (+ megbízható alkatrész) Alapfeltétel: Redundancia (tartalékolás) o többlet erőforrások a hibás komponensek kiváltására 29

Redundancia megjelenése 1. Hardver redundancia o többlet hardver erőforrások eleve a rendszerben lévők (elosztott rendszer) hibatűréshez betervezett (tartalék) 2. Szoftver redundancia o többlet szoftver modulok 3. Információ redundancia o többlet információ a hibajavítás érdekében hibajavító kódolás (ECC) 4. Idő redundancia o ismételt végrehajtás, hibakezelés többlet ideje Együttes megjelenés! 30

Redundancia típusai Hidegtartalék (passzív redundancia): o normál üzemmódban passzív, hiba esetén aktiválva o lassú átkapcsolás (elindítás, állapot frissítés,...) o pl. tartalék számítógép Langyos tartalék: o normál üzemmódban másodlagos funkciók o gyorsabb átkapcsolás (indítást nem kell várni) o pl. naplózó gép átveszi a kritikus funkciókat Meleg tartalék (aktív redundancia): o normál üzemmódban aktív, ugyanazt a feladatot végzi o azonnal átkapcsolható o pl. kettőzés, többszörözés 31

1. Hardver redundancia Többszörözés o Kettőzés hibadetektálás: pl. master-checker kialakítás hibatűrés csak diagnosztikai támogatással és átkapcsolással o TMR: Triple-modular redundancy hiba maszkolás szavazással szavazó kritikus elem (de egyszerű) o NMR: N-modular redundancy hibamaszkolás többségi szavazással MTFF kisebb, de missziós idő túlélése nagyobb esélyű repülőgép fedélzeti eszközök: 4MR, 5MR Tipikus: nagy rendelkezésre állású fürtök 32

Többszörözés szintje Számítógép (szerver) szint: Lazán csatolt o nagy rendelkezésre állású fürtök pl. Sun Cluster, HA Linux, Windows Failover Cluster o szoftver támogatás: állapotszinkronizálás, tranzakciók Kártya szint: o futásidőbeli átkonfigurálás, hot-swap pl. compactpci, HDD o szoftver támogatás: konfigurációkezelés Alkatrész szint: Szorosan csatolt o alkatrész szintű többszörözés pl. TMR, önellenőrző áramkörök 33

2. Szoftver redundancia Használat: 1. Szoftver tervezési hibák esetén: o ismételt végrehajtás nem segít... o redundáns modulok: eltérő tervezés szükséges variánsok: azonos specifikáció, de eltérő algoritmus, adatstruktúrák más fejlesztési környezet, programnyelv elszigetelt fejlesztés 2. Időleges (hardver) hibák esetén: o ismételt végrehajtás esetén a hiba nem jelentkezik o hibahatások kiküszöbölése a fontos 35

3. Információ redundancia Hibajavító kódolás o memóriák. háttértárak, adatátvitel o pl. Hamming-kód, Reed-Solomon kódok Korlátozott hibajavító képesség o hosszú idejű adatstabilitás rossz lehet ( felgyűlnek a hibák) o háttértárak: memory scrubbing folyamatos olvasás és javítva visszaírás Redundáns (többpéldányos) adatbázisok: o hozzáférések konzisztenciájának biztosítása o egypéldányos sorosíthatóság 36

4. Idő redundancia Tiszta eset: utasítás újrapróbálás (retry) o alacsony hardver szinten: processzor utasítás o időleges hibák esetén hatásos Idő redundancia velejárója a többi típusnak Valósidejű rendszerek: tervezési szempont mennyire garantálható a hibakezelés ideje o állandósult hardver hibák: maszkolás, meleg tartalék o időleges hardver hibák: előrelépő helyreállítás o szoftver tervezési hibák: N-verziós programozás a(t), válaszidő SLA fontos tényezője 37

Hibák kezelése Hardver tervezési hibák (< 1%): o nincs figyelembe véve (ld. jól tesztelt komponensek) Hardver állandósult működési hibák (10%): o hardver redundancia (pl. tartalék processzor) Hardver időleges működési hibák (70-80%): o idő redundancia (pl. utasítás újravégrehajtás) o információ redundancia (pl. hibajavítás) o szoftver redundancia (pl. állapotmentés és helyreállítás) Szoftver tervezési hibák (10-20%): o szoftver redundancia (pl. eltérő tervezésű modulok) 38

Költségoptimalizálás hibatűrés költsége kialakítási költség hibatűrés mértéke 39

Költségoptimalizálás hibatűrés költsége kialakítási költség üzemeltetési költség hibatűrés mértéke 40

Költségoptimalizálás hibatűrés költsége eredő kialakítási költség üzemeltetési költség optimum hibatűrés mértéke 41

Példa 5: Airbus A-320 Önellenőrző blokkok (4 variáns) Aktuális pár és átkapcsolás hiba esetén Állandósult hardver hiba: Hibás pár lekapcsol V1 V2 V3 V4 H H H H 42

Tartalomjegyzék A szolgáltatásbiztonság fogalma A szolgáltatásbiztonságot befolyásoló tényezők A szolgáltatásbiztonság eszközei Szolgáltatásbiztonság analízise 43

Szolgáltatásbiztonság analízise Miért van szükség analízisre? o Ha bőséges redundanciát biztosítunk, az nem elég? A redundancia költséges Csak a jól tervezett redundancia éri el a célját! o Mennyiség o Hideg / meleg o Javítás o 44

Példa 3 merevlemezből álló RAID-5 tömb o Két lemeznyi hasznos terület, plusz paritás o Egy lemez meghibásodását tűri 8 állapot: {Up/Down} 3 o Köztük λ állapotátmeneti ráták UUU λ λ λ DUU UDU UUD DDU DUD UDD 3 UP 2 UP 1 UP 45 λ λ λ λ λ λ λ λ λ DDD 0 UP

Példa 3 merevlemezből álló RAID-5 tömb o Két lemeznyi hasznos terület, plusz paritás o Egy lemez meghibásodását tűri Azonos állapotok összevonhatóak o Azonos rendszerszintű következmény és kimenetek UUU λ λ λ DUU UDU UUD λ λ λ λ λ λ DDU DUD UDD DDD 3 UP 2 UP 1 UP 0 UP 46 λ λ λ

Példa 3 merevlemezből álló RAID-5 tömb o Két lemeznyi hasznos terület, plusz paritás o Egy lemez meghibásodását tűri Azonos élek összevonhatóak o Állapotátmeneti ráta összeadódik! UUU λ λ λ λ DUU UDU UUD λ 3 UP 2 UP λ λ λ 1 λ λ 1 UP 47 0 0 UP

Példa 3 merevlemezből álló RAID-5 tömb o Két lemeznyi hasznos terület, plusz paritás o Egy lemez meghibásodását tűri Eljárás folytatása λ DUU 2λ UUU λ UDU 2λ 1 λ 0 λ UUD 2λ 3 UP 2 UP 1 UP 0 UP 48

Példa 3 merevlemezből álló RAID-5 tömb o Két lemeznyi hasznos terület, plusz paritás o Egy lemez meghibásodását tűri o Első meghibásodás rátája: 3λ (meleg tartalék mindhárom lemez kieshet!) 3λ 2λ λ 3 2 1 0 o MTTF: 1/3λ + 1/2λ = 5/6λ o 5/6λ < 1/λ egy lemez jobb! 49

Példa A redundancia rontotta a megbízhatóságot! Megoldás: a kiesett lemezt gyorsan cserélni kell o Javítási folyamat felvétele a Markov-láncba 3λ 2λ λ μ μ μ Másik példa: három villanykörte, hideg tartalék λ λ λ 50

Feladatok: Szolgáltatásbiztonság analízise o Hibamódok, meghibásodások azonosítása o Analízis: kvalitatív és kvantitatív Módszerek o Ellenőrző listák o Táblázatok (pl. FMEA: Failure Mode and Effect Analysis) o Hibafák o Állapot alapú módszerek (pl. Petri hálók) o 51

Technika: Ellenőrző lista o Tapasztalatok rendszerezett összegyűjtése o Alkalmazás mint ökölszabályok Biztosítja: o Ismert hibaforrások nem maradnak ki o Kipróbált módszereket alkalmaz Hátrányok: o A lista nem teljes és nehezen kezelhető o Téves biztonságérzetet ad o Más környezetben az alkalmazhatóság kérdéses 52

Hibamód és hatás analízis (FMEA) Meghibásodás és hatásaik felsorolása Komponens Hibamód Valószínűség Hatás Webszerver HW hiba 10% Szolg. kiesés, alkatrész csere SW frissítés 90% Időleges kiesés SQL szerver Diszk megtelik 20% Csak statikus tartalom érhető el 53

Példa: Vezérlő elektronika Számított Hibamód Hatás Valószínűség 54

Kvalitatív: Hibafa analízis o egyszeres hibapont (SPOF) azonosítása o kritikus esemény: több úton is hibajelenséget okoz Kvantitatív: o alapszintű eseményekhez valószínűség rendelése (nehéz: honnan lesznek jó adataink?) o gyökérelem jellemzőjének (pl. megbízhatóság) számolása o Problémák: nem független események 55

Hibafa grafikus elemkészlet legfelső szintű vagy közbenső esemény elsődleges (alapszintű) esemény tovább nem vizsgált esemény normál esemény (nem hiba vagy veszély) feltétel egy összetett esemény bekövetkezéséhez ÉS kapu VAGY kapu 56

Hibafa példa: Felvonó Felvonó beragad Legfelső szintű veszély 57

Hibafa példa: Felvonó Boole-logikai kapcsolat Felvonó beragad Legfelső szintű veszély Gomb beragad Tápfesz. kiesés Vezérlő hiba Közbenső esemény Tovább nem vizsgált esemény 58

Hibafa példa: Felvonó Boole-logikai kapcsolat Felvonó beragad Legfelső szintű veszély Gomb beragad Tápfesz. kiesés Vezérlő hiba Közbenső esemény Tovább nem vizsgált esemény 380V kiesés UPS kiesés Vezérlő hardver hiba Vezérlő szoftver hiba Elsődleges események Elsődleges proc. hiba Tartalék proc. hiba 59

Hibafa példa: Szoftver minta IF-THEN-ELSE hiba Feltétel kiértékelés hiba Feltétel TRUE, THEN ág hiba Feltétel FALSE, ELSE ág hiba Feltétel TRUE THEN ág hiba ELSE ág hiba Feltétel FALSE Utasítás1 hiba Utasítás2 hiba 60

Minőségi (kvalitatív) analízis Hibafa redukció: Közbenső események és pszeudo-események feloldása diszjunktív normál forma (OR a legtetején) Vágat: AND kapuval összefogott elsődleges események Minimális vágathalmaz: Nem redukálható o Nincs olyan, aminek részhalmaza is megtalálható Azonosítható: o egyszeres hibapont (SPOF) o kritikus esemény (több vágatban is szerepel) 61

Hibafa példa: Felvonó Felvonó beragad Gomb beragad Tápfesz. kiesés Vezérlő hiba 380V kiesés UPS kiesés Vezérlő hardver hiba Vezérlő szoftver hiba Elsődleges proc. hiba Tartalék proc. hiba 62

Redukált hibafa példa: Felvonó Felvonó beragad Gomb beragad 380V kiesés UPS kiesés Elsődleges proc. hiba Tartalék proc. hiba Vezérlő szoftver hiba SPOF lehet SPOF 63

Mennyiségi (kvantitatív) analízis Alapszintű eseményekhez rendelt valószínűségek o komponens-adat, tapasztalat, becslés Kiindulás: redukált hibafa Rendszerszintű veszély valószínűség számítása o AND kapu: szorzat (ha független események) pontos: P{A és B} = P{A}P{B A} o OR kapu: összegzés (felső becslés) pontos: P{A vagy B} = P{A}+P{B}-P{A és B}<=P{A}+P{B} Problémák: o korreláló hibák o időbeli (hiba)szekvenciák kezelése 64

Meghibásodási adatok Analízis alapja: meghibásodási valószínűségek Honnan lesznek jó adatok: o Becslés o Saját monitorozó rendszer o Külső tanulmányok, számok (hihetőség, pontosság?) Példák: o Cisco switch MTBF ~ 200000 óra (=22,8 év) o IBM S/390 mainframe MTTF 45 év o Windows XP MTTF 608 óra o webszerver MTTF ~ 16 nap 66

Állapot alapú módszerek Hibák kvalitatív leírása: diszkrét viselkedésmodell o Állapotgép, adatfolyamháló, folyamat, Petri-háló o Pl. folyamatmodellben: hibakezelési ágak Kvantitatív leírás: o Időzítés, valószínűség az állapotátmenetekhez o Determinisztikus (nincs választási pont, csak véletlen) o Valószínűségi eloszlás alapján: folytonos vagy diszkrét idejű, markovi sztochasztika 67

Példa: szolgáltatásbiztonság analízise Feladat: Milyen meghibásodások esetén nem lesz elérhető a szolgáltatás (webáruház)? 68

Feladat: Meghibásodások azonosítása Milyen meghibásodás esetén nem lesz elérhető a szolgáltatás (webáruház)? Áramkimaradás, HW hiba, hálózati elem/kábel hiba, szerver szolgáltatások hibája, alkalmazás hiba, frissítés telepítése, túlterhelés, támadás, félrekonfigurálás, verzió inkompatibilitás, vírus 69

Példa: hibatűrés beépítése Másodlagos DNS szerver alkalmazása 2. ISP használata Terheléselosztó fürt Hálózati utak duplikálása 70 Melegtartalék SQL szerver

Példa: hibatűrés beépítése Hibatűrő a rendszerünk? 71

Példa: hibatűrés beépítése Hibatűrő a rendszerünk? Attól függ: DE o Bizonyos SPOF-ek ellen védekeztünk o sok kiesési lehetőség maradt még o Adatok törlése, teljes szerverterem elpusztulása, adminisztrátori hibák, OS hotfix miatti újraindítás 72

Példa: hibatűrés beépítése Hibatűrő a rendszerünk? Attól függ: DE Tanulság: mindig tudjuk, hogy o Bizonyos SPOF-ek ellen védekeztünk mi ellen akarunk védekezni, milyen módszerek vannak arra, o sok kiesési lehetőség maradt még megéri-e védekezni o Adatok törlése, teljes szerverterem elpusztulása, adminisztrátori hibák, OS hotfix miatti újraindítás 73

SHARPE eszköz Hibafa rajzolása Analízis: hibafa 74

Analízis: hibafa Alapszintű meghibásodásokhoz bekövetkezési valószínűség rendelése Megbízhatóság számolása: 75

TimeNET eszköz Analízis: Petri-háló Alap blokkok és paraméterek 76

Analízis: Petri-háló A teljes modell: 77

Analízis: érzékenység és költségvizsgálat Érzékenység: melyik paraméter változása befolyásol a legjobban: Költségoptimalizálás: Költség Rendelkezésre állás Kiesés Kiesés költsége Nyereség Alapmodell 0 0,904 34,931 3 493 050,000 Tartalék SQL 500 000 0,913 31,792 3 179 150,000-186 100,000 Tartalék web 500 000 0,921 28,945 2 894 450,000 98 600,000 Tartalék mindkettőből 1 000 000 0,930 25,733 2 573 250,000-80 200,000 Web szerver 1 000 000 0,914 31,463 3 146 300,000-653 250,000 SQL szerver 2 000 000 0,914 31,536 3 153 600,000-1 660 550,000 Web szerver + tartalék 2 000 000 0,933 24,565 2 456 450,000-963 400,000 SQL szerver + tartalék 3 000 000 0,936 23,506 2 350 600,000-1 857 550,000 78

Hiba hatásának becslése Egy művelet/erőforrás lehet jó / hibás / hiányos / késői rendszer viselkedése? Alapelv o Hibaokok/hibamódok (fault) erőforráshoz rendelése o Hiba útjának követése (ERROR) o Érinti-e a szolgáltatást (FAILURE)? 79 79

Hibaterjedés modellezése Adat/vezérlési tokenek színezése pl. jó/ hibás / gyanús Kvalitatív közelítés Egy potenciálisan hibás komponens utáni lépések legalább gyanúsak Statikus o Kárbehatárolási tartomány (Damage Confinement Region) Dinamikus ellenőrzés? o Jobb közelítés o Nehezebb meghatározni 80

Teljes modell: Példa IF credit_requested < 2.000.000 THEN approval(director) ELSE approval(board) Determinisztikus közelítés (absztrakció): IF minor_credit_requested THEN approval(director) ELSE approval(board) o Nem reprezentáljuk a credit_requested értéket o Csak egy bináris változó határozza meg a működést (minor_credit_requested) o Nem számít, ha az érték változik (2.000.000 ) Nemdeterminisztikus absztrakció CHOOSE (approval(director), approval(board)) o Nem foglalkozunk az értékekkel (credit_requested) o Még a döntési logikát sem írjuk le o Részletek véletlen viselkedés 81

Adatfolyamhálók (ism.) Csomópont (Port) Állapot Variable Uninitialized Written Read Written and read Fault written Fault written and read G(Variable.state!=Fault_written) Token Activity Control Data D_F_Control Csatorna 82 82

Hibamodellezés adatfolyamhálóval Kvalitatív hibamodell adatfolyamháló o Komponens adatfolyam csomópont o Belső hibamódok csomópont állapotai o Komponens kapcsolatok csatornák o Kommunikációs hibamódok csatorna tokenek R0: in1.ok, in2.ok / out1.ok, out2.ok in1 Ok / Omission / Compromised UP R1: in1.-, in2.failed / out1.corrupted,out2.omission F Ok / Omission / Corrupted out1 in2 Ok / Failed / RangeViolation DN Ok / Late / Omission out2 83

Munkafolyamat adatfolyamháló Policy Recording Establish type Premium Recording Establish type Policy Beginning of parallel execution Premium End of parallel Execution 84 84

Szolgáltatásbiztonság Összefoglalás o Jellemzők, hatáslánc, eszközök Hibatűrés o Redundancia megjelenése Analízis: o Mérnöki és matematikai módszerek o Hibamódok azonosítása o Megfelelő védekezési módszer kiválasztása 85