Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- statnice:oi_si_pis_stabilita_spolehlivost_systemu [2011/05/29 18:29]
vlk
+++ statnice:oi_si_pis_stabilita_spolehlivost_systemu [2025/01/03 18:23] (aktuální)
@@ Řádek 1: / Řádek 1: @@
 ====== Stabilita a spolehlivost systému, MTBF (mean time between failures), dostupnost systému (uptime), redundance, návrh vysoce robustních systémů.(A0M33PIS) ======
-===== DRAFT - dokoncim v nedeli odpo =====
 **Spolehlivost** = schopnost systému nebo součásti vykonávat požadované funkce za daných podmínek po určené časové období
@@ Řádek 7: / Řádek 5: @@
 **Dostupnost** = charakteristika představující úroveň, do které je systém nebo součást funkční a k dispozici v případě, že je vyžádáno její použití. Dostupnost lze považovat za pravděpodobnost, že se systém nebo součást nachází ve stavu, kdy umožňuje provádět požadované funkce za určených podmínek a v daném časovém okamžiku.
 Dostupnost se vypočítává jako MTBF / (MTBF + MTTR)
-Příklad: dostupnost 99,99% pro 24x7x365: celkem 8760, TTR = 0,876 hod.
+Příklad: dostupnost 99,99% pro 24x7x365: celkem 8760, TTR = 0,876 hod.
-Bezpečnost je schopnost systému bude buďto pracovat správně, nebo ukončit
+Bezpečnost je schopnost systému bude buďto pracovat správně, nebo ukončit
-svoji činnost takovým způsobem, že nenaruší činnost jiného systému.
+svoji činnost takovým způsobem, že nenaruší činnost jiného systému.
 **MTBF**
-Střední doba mezi poruchami (MTBF, Mean Time Between Failures) - statistická veličina, sloužící k ohodnocení spolehlivosti systému, u kterého se předpokládá okamžitá oprava. MTBF lze počítat takto: \\
+  * http://en.wikipedia.org/wiki/Mean_time_between_failures
-''MTBF = Suma(downtime - uptime) / NumberOfFailures''
+Střední doba mezi poruchami (MTBF, Mean Time Between Failures) - statistická veličina, sloužící k ohodnocení spolehlivosti systému, u kterého se předpokládá okamžitá oprava. MTBF lze počítat takto: \\
+''MTBF = Suma(začátek výpadku - konec předchozího výpadku) / NumberOfFailures''
-Pravděpodobnost, že systém bude pracovat bez poruchy po dobu T (spolehlivost systému): \\
+Pravděpodobnost, že systém bude pracovat bez poruchy po dobu T (spolehlivost systému): \\
 ''R(T) = e^-(T/MTBF)''
-Příklad: Systém s MTBF 250.000 hod., plánovaná doba nepřetržitého provozu 5 let (43.800 hod):
+Příklad: Systém s MTBF 250.000 hod., plánovaná doba nepřetržitého provozu 5 let (43.800 hod):
-tj. je pravděpodobnost 83.9%, že systém bude pracovat 5 let bez poruchy (respektive, že 83,9% z provozovaných systémů bude po 5 letech stále pracovat).
+tj. je pravděpodobnost 83.9%, že systém bude pracovat 5 let bez poruchy (respektive, že 83,9% z provozovaných systémů bude po 5 letech stále pracovat).
-MTBF je často chybně interpretována jako předpokládaný počet provozních hodin před selháním systému nebo jako „servisní životnost“.
+MTBF je často chybně interpretována jako předpokládaný počet provozních hodin před selháním systému nebo jako „servisní životnost“.
-MTBF jsou založeny na pravděpodobnosti poruch produktu při „běžných podmínkách“ nebo „při standardním provozu“ a předpokládá se, že pravděpodobnost poruchy se s časem nemění a je stejná bez ohledu na dobu provozu. V této fázi životnosti produktu se dosahuje nejnižší (a konstantní) pravděpodobnosti poruchy.
+MTBF jsou založeny na pravděpodobnosti poruch produktu při „běžných podmínkách“ nebo „při standardním provozu“ a předpokládá se, že pravděpodobnost poruchy se s časem nemění a je stejná bez ohledu na dobu provozu. V této fázi životnosti produktu se dosahuje nejnižší (a konstantní) pravděpodobnosti poruchy.
-Provoz systému omezuje doba jeho životnosti, která je podstatně kratší než hodnoty MTBF. Je docela možné vyrobit produkt s extrémně vysokou spolehlivostí (MTBF), který však bude mít krátkou očekávanou životnost. Dále se vyskytuje metrika střední doba do poruchy (MTTF, Mean Time to Failure), což je stejně počítaná metrika ovšem pro zařízení, která se neopravují. Charakteristika MTBF se obvykle odhaduje na základě sledování vzorku podobných systémů, který je obvykle analyzován po implementaci dostatečně velkého počtu produktů do provozu.
+Provoz systému omezuje doba jeho životnosti, která je podstatně kratší než hodnoty MTBF. Je docela možné vyrobit produkt s extrémně vysokou spolehlivostí (MTBF), který však bude mít krátkou očekávanou životnost. Dále se vyskytuje metrika střední doba do poruchy (MTTF, Mean Time to Failure), což je stejně počítaná metrika ovšem pro zařízení, která se neopravují. Charakteristika MTBF se obvykle odhaduje na základě sledování vzorku podobných systémů, který je obvykle analyzován po implementaci dostatečně velkého počtu produktů do provozu.
 **MDT**
-Střední doba výpadku (MDT, mean down time) - střední doba, po kterou je systém mimo provoz. Zahrnuje veškeré časy opravy, preventivní údržby, odstávky aj.
+Střední doba výpadku (MDT, mean down time) - střední doba, po kterou je systém mimo provoz. Zahrnuje veškeré časy opravy, preventivní údržby, odstávky aj.
 **MTTR**
-Střední doba opravy (obnovy) (MTTR, Mean Time to Repair) - očekávaný časový interval, během kterého dojde k obnovení systému po poruše. Zahrnuje čas pro diagnostiku a celkovou dobu opravy systému.
+Střední doba opravy (obnovy) (MTTR, Mean Time to Repair) - očekávaný časový interval, během kterého dojde k obnovení systému po poruše. Zahrnuje čas pro diagnostiku a celkovou dobu opravy systému.
-MTTR je obvykle součástí servisní smlouvy na údržbu IS - „měkká“ podmínka, negarantuje absolutní čas, ale průměrnou trendovou hodnotu. Vhodnější je použít charakteristiku „maximální doba opravy“. Někteří dodavatelé interpretují MTTR jako „mean time to respond“, tj. reakční doba bez garance odstranění poruchy.
+MTTR je obvykle součástí servisní smlouvy na údržbu IS - „měkká“ podmínka, negarantuje absolutní čas, ale průměrnou trendovou hodnotu. Vhodnější je použít charakteristiku „maximální doba opravy“. Někteří dodavatelé interpretují MTTR jako „mean time to respond“, tj. reakční doba bez garance odstranění poruchy.
 ===== Spolehlivostní modely =====
@@ Řádek 48: / Řádek 47: @@
 ===== Metody Fault Tolerant systémů =====
 Definice názvosloví Chyba -> Porucha -> Selhání -> Havárie \\
-Chyba: neošetřená výjimka v ovladácím programu vodárny \\
+''Příklad:\\
+Chyba: neošetřená výjimka v ovladácím programu vodárny\\
 Porucha: systém otevírá ventil \\
-Selhání: vodárna přeteče \\
+Selhání: vodárna přeteče\\
-Havárie: zaplavená hala
+Havárie: zaplavená hala\\
+Systém nebyl navržen s ohledem na správnou reakci - není Fault Tolerant''
-Systém nebyl navržen s ohledem na správnou reakci - není Fault Tolerant
+Základní postupy při návrhu FT systémů, kterými eliminujeme (minimalizujeme) vliv chyb na systém:
-Základní postupy při návrhu FT systémů, kterými eliminujeme (minimalizujeme) vliv chyb na systém:
 {{:statnice:si_10_fault_tolerant.png|}}
-Použití jak pro hardwarovou, tak i pro softwarou část řešení.
+Použití jak pro hardwarovou, tak i pro softwarou část řešení.
+Některé návrhy systémů v návaznosti na spolehlivostní modely jsou popsány níže. Je tím i pokryto téma redundance.
+===== Redundance =====
+Výsledná spolehlivost IS je určena současně:
+  * **hardwarovou** spolehlivostí, tj. spolehlivostí technické infrastruktury,
+  * **softwarovou** spolehlivostí, tj. spolehlivostí algoritmizace a softwarové realizace,
+  * **informační** spolehlivostí, tj. spolehlivostí přenosu, zpracování a uchovávání informací,
+  * spolehlivostí **lidského činitele**.
+Cílem je zabezpečit odolnost proti vytipovaným poruchám s nejkritičtějšími následky. Prostředky jsou:
+  * použití redundantního technického vybavení, tzv. hardwarového zálohování,
+  * použitím softwarové redundance s využíváním návrhu programů s ohledem na spolehlivost, tj.
+    * začleněním kontrolních funkcí, resp. algoritmů diagnostiky,
+    * při programové realizaci využíváním jednoduchých programových struktur s vhodnou volbou kontrolních bodů,
+    * využíváním analytických metod testování a verifikací navržených programů;
+    * opakování téhož výpočtu podle různých algoritmů
+    * využívání nadbytečnost informační - použití např. redundantního kódováni
+Pozn.: //Softwarová redundance// – realizace stejného algoritmu různými dodavateli, v odlišném programovacím jazyce, odlišném vývojovém prostředí, pro odlišný operační systém. Není to moc časté a jedná se zejména o kritické softwarové systémy např. pro armádní projekty atp.
+=== Systémy M z N ===
+Generalizace ideálních paralelních systémů. V M z N systému je nutné ke správné činnosti systému jeho M prvků z celkových N prvků.
+=== DMR a TMR systémy ===
+**DMR** (Dual Modular Redundand) - pouze zdvojení \\
+**TMR** (Triple Modular Redundand) - uspořádání tří prvků tak, aby výpadek jednoho vedl k maskování poruchy v systému.
+=====Návrh vysoce robustních systémů=====
+Toto téma obsahuje výše zmíněnou problematiku redundance, dále se sem hodí další kapitoly:
+==== Zálohování ====
+  * **Substituční zálohování s pohyblivou zálohou** – skupina stejných prvků má jeden nebo několik záložních prvků a v případě poruchy kteréhokoliv z prvků základní skupiny je na jeho místo připojen záložní prvek (resp. jeden ze skupiny záložních prvků).
+  * **Zálohování se sdílením zátěže** – při normálním pracovním režimu jsou realizované funkce, resp. zatížení rozloženy např. na dva prvky, které pracují v částečně odlehčeném režimu a jsou dimenzovány tak, že v případě poruchy jednoho z nich přebírá druhý prvek všechny funkce, resp. celé zatížení, a pracuje pak s nominálním, resp. maximálním zatížením, zpravidla navíc při určitém (nevýznamném) omezení rozsahu funkcí systému.
+  * **Zálohování s obecnější rekonfigurací struktury** – dynamické zálohování s obnovou prvků po poruše a s rekonfigurací poruchových modelů. Např. z výchozího majoritního zálohování dva ze tří se po poruše libovolného prvku přechází na paralelní systém se dvěma prvky a po eventuální další poruše zbývá neporouchaný pouze základní prvek. Struktura bývá rekonfigurována automaticky s využitím tzv. diagnostického procesoru, na který navazuje činnost rekonfigurační jednotky.
+==== Škálovatelnost (rozšiřitelnost) ====
+Je vlastnost systému, indikující jeho schopnost přizpůsobit se rostoucím požadavkům na kapacitu, výkon, odezvu, dostupnost systému a atd., popřípadě být připraven na rozšíření. Škálovatelnost je často omezena návrhem/implementací systému.
+Dimenze škálovatelnosti:
+  * **Load scalability**: Schopnost distribuovaných systémů rozšířit/zúžit využitelné zdroje v závislosti na zátěži. Alternativně, schopnost snadné modifikace systému nebo komponenty podle zátěže.
+  * **Geographic scalability**: Schopnost udržet výkonnost, použitelnost atd. v podmínkách geografického rozšiřování.
+  * **Functional scalability**: Schopnost rozšiřování systému o nové funkcionality s minimalizací úsilí.
+Kategorie škálovatelnosti
+  * **Vertikální škálovatelnost (scale up)** = přidávání zdrojů jednomu uzlu systému (typicky přidání procesoru, rozšíření paměti), včetně rekonfigurace pro využití nových zdrojů (např. zvětšení počtu démonů Apache web serveru)
+  * **Horizontální škálovatelnost (scale out)** = přidávání nových uzlů do systému (typicky u distrib.aplikací), např. rozšíření z jednoho webserveru na tři, rozšíření gridu, zvýšení počtu procesoru
+====Zajištění odezvy systému – RT systémy====
+Dvě definice:
+**Systém reálného času** (real-time system) - informační systém, který zpracovává asynchronní vstupy a produkuje odpovědi v pevně stanoveném čase. Doba, kterou má systém k dispozici pro provedení úlohy, je známa předem. Na počtu vstupů a jimi vyvolané pracovní zátěži systému přitom nezáleží.
+**Systém reálného času** - informační systém, který zpracovává asynchronní vstupy a produkuje odpovědi. Potřebný čas může být odvozen ze zátěže systému. Tento čas musí být ohraničený -> nejdelší možná doba odezvy.
-Softwarová redundance – realizace stejného algoritmu různými dodavateli, v odlišném programovacím jazyce, odlišném vývojovém prostředí, pro odlišný operační systém. Není to moc časté a jedná se zejména o kritické softwarové systémy např. pro armádní projekty atp.
+Rozlišujeme:
+  * **hard RT** - systém vždy musí splnit daný časový termín (např. řízení létajícího prostředku, jaderného reaktoru aj.)
+  * **soft RT** - konkrétní časové okamžiky mohou být zmeškány. (např. optimalizace spotřeby paliva v motoru).
+Požadavky pro RTOS (realtime operating system) definuje standard Posix 1003.1b, Real-time extensions (Priority Scheduling, Real-Time Signals, Clocks and Timers, Semaphores, Message Passing, Shared Memory, Asynch and Synch I/O, Memory Locking Interface) – dnes implementováno např. v RTOS Lynx, QNX, VxWork, RTLinux ale i částečně Solaris, Linux, FreeBSD.

statnice/oi_si_pis_stabilita_spolehlivost_systemu.1306686571.txt.gz · Poslední úprava: 2025/01/03 18:19 (upraveno mimo DokuWiki)

Nahoru