System wiarygodny

Transkrypt

System wiarygodny

WIARYGODNOŚĆ
(1)
INSTYTUT
INFORMATYKI
WIARYGODNOŚĆ
= pewność działania systemu, która pozwala mieć uzasadnione zaufanie do usług,
które ten system dostarcza
System wiarygodny
= dyspozycyjny (available) – dostępny na bieżąco
= niezawodny (reliable) – odporny na awarie
= bezpieczny (secure) – zapewniający ochronę danych
= bezpieczny (safe) – dla środowiska
© Michał Szychowiak, 2003
Wiarygodność Systemów Rozproszonych (Wykład wprowadzający)
WIARYGODNOŚĆ
(2)
INSTYTUT
INFORMATYKI
Podstawowe definicje
defekt (failure) – występuje gdy system przestaje być zgodny ze specyfikacją
błąd (error) – część stanu systemu odpowiedzialna za będący jego następstwem
defekt – symptom defektu, który właśnie lub wcześniej wystąpił
uszkodzenie / awaria (fault) – stwierdzona lub hipotetyczna przyczyna wystąpienia
błędu [1]
FAULT
Manufacturing
problems
Erroneous
system
state
Design
errors
External
disturbances
Error
Fatigue &
deterioration
Process/System Failure
WIARYGODNOŚĆ
(3)
INSTYTUT
INFORMATYKI
Wiarygodność =
zapobieganie uszkodzeniom (fault prevention): jak zapobiec wystąpieniu lub
dostarczanie
wprowadzeniu uszkodzeń
wiarygodności
(procurement)
tolerowanie uszkodzeń (fault tolerance): jak zapewnić zgodność usługi ze
specyfikacją mimo uszkodzeń
usuwanie uszkodzeń (fault removal): jak ograniczyć obecność (liczbę,
walidacja
dotkliwość) uszkodzeń
wiarygodności
(validation)
prognozowanie uszkodzeń (fault forecasting): jak oszacować aktualną liczbę,
możliwość przyszłego wystąpienia oraz konsekwencje uszkodzeń
WIARYGODNOŚĆ
(4)
INSTYTUT
INFORMATYKI
Podstawowe definicje (2)
naruszenia (impairments) wiarygodności – niepożądane i na ogół nieoczekiwane
okoliczności powodujące lub wynikające z niewiarygodności,
środki zapewniające (means) wiarygodność – zapobieganie uszkodzeniom,
tolerowanie uszkodzeń, usuwanie i prognozowanie uszkodzeń – metody i techniki
pozwalające z jednej strony zapewnić zdolność dostarczania usługi , do której można
mieć zaufanie, a z drugiej – osiągnąć zaufanie w tę zdolność
atrybuty (attributes) wiarygodności – parametry pozwalające oszacować własności
oczekiwane od systemu oraz oszacować jakość systemu z uwzględnieniem naruszeń
wiarygodności i przeciwdziałających im środków
WIARYGODNOŚĆ
(5)
INSTYTUT
INFORMATYKI
Drzewo wiarygodności
WIARYGODNOŚĆ
NARUSZENIA
ATRYBUTY
ŚRODKI
− uszkodzenia
− błędy
− defekty
−
−
−
−
DOSTARCZANIE
− profilaktyka
− tolerowanie
dostępność
niezawodność
bezpieczeństwo
ochrona
WALIDACJA
− usuwanie
− prognozowanie
NARUSZENIA WIARYGODNOŚCI
(1)
INSTYTUT
INFORMATYKI
Uszkodzenia
Natura uszkodzeń:
uszkodzenia przypadkowe
uszkodzenia umyślne
Źródło uszkodzeń:
uszkodzenia fizyczne
uszkodzenia spowodowane przez człowieka
Granice źródła uszkodzeń:
uszkodzenia wewnętrzne
uszkodzenia zewnętrzne
(2)
INSTYTUT
INFORMATYKI
Faza powstania uszkodzeń:
uszkodzenia projektowe
uszkodzenia operacyjne
Trwałość uszkodzeń:
uszkodzenia trwałe (permanent)
uszkodzenia przemijające (transient) / przerywane (intermittent)
Przykłady:
− uszkodzenie projektowe jest wynikiem defektu spowodowanego przez projektanta
− uszkodzenie zewnętrzne fizyczne lub spowodowane przez człowieka jest de facto
uszkodzeniem projektowym: niemożność przewidzenia wszystkich sytuacji lub
rezygnacja z rozpatrywania niektórych z nich (np. w przypadku wystąpienia
zakłócenia elektromagnetycznego: czy jest to uszkodzenie zewnętrzne, czy brak
odpowiedniego ekranowania?)
(3)
INSTYTUT
INFORMATYKI
Błędy
błąd odpowiada za defekt
wystąpienie błędu doprowadzi faktyczne do defektu w zależności od:
budowy systemu (w szczególności np. istnienia redundancji)
działanie systemu (błąd może zostać skasowany np. przez zapisanie
nowych danych zanim spowoduje szkody)
postrzegania defektu przez użytkownika (np. czas przestoju systemu może
być, albo nie, postrzegany jako defekt w zależności od ziarnistości czasu
konkretnego użytkownika)
wykonanie α
. . .
T1
. . .
T2
wykonanie β
defekt
. . .
stan poprawny
wykonanie γ
stan błędny
(4)
INSTYTUT
INFORMATYKI
Defekty
Kryterium dziedziny defektu:
defekty wartości (value failures)
defekty synchronizacji (timing failures)
Kryterium percepcji defektu:
defekty zgodne (consistent failures) – wszyscy użytkownicy zgodnie
postrzegają ten sam defekt
defekty niezgodne (inconsistent failures) – użytkownicy różnie postrzegają
ten sam defekt
Kryterium dotkliwości defektu:
defekty łagodne (benign failures) – konsekwencje są tego samego rzędu,
co korzyści wynikające z dostarczanej usługi przy braku defektu
defekty katastroficzne (catastrophic failures) – konsekwencje
nieporównywalnie większe
(5)
INSTYTUT
INFORMATYKI
Podstawowe klasy defektów:
zatrzymanie (stopping failures) – praca systemu przestaje być
dostrzegalna dla użytkowników – należą zarówno do typu defektów
wartości jak i synchronizacji
zaniechanie (omission failures) – specjalny typ klasy zatrzymania –
graniczny przypadek defektów wartości (wartość nieistotna)
i synchronizacji (nieskończone opóźnienie)
upadek (crash failures) – trwały defekt zaniechania
bizantyjskie (Byzantine failures, malicious failures) – arbitralne defekty
niezgodne (najogólniejsza klasa)
(6)
INSTYTUT
INFORMATYKI
Patologia uszkodzeń
Mechanizmy powstawania i ujawniania się uszkodzeń, błędów i defektów
uszkodzenie jest aktywne (active) wtedy, gdy powoduje błąd; jest ono:
uszkodzeniem wewnętrznym, które było uśpione (dormant) lub
uszkodzeniem zewnętrznym
błąd może być:
ukryty (latent) – jeszcze nie rozpoznany
wykryty (detected) przez algorytm lub mechanizm detekcji błędów
defekt elementu powoduje uszkodzenie w
systemie zawierającym ten element
elementach, z którymi prowadził interakcje (klasa defektu uszkodzonego elementu staje
się klasą pochodnych uszkodzeń)
Łańcuch podstawowy: ...
defekt
uszkodzenie
błąd
defekt
...
RELIABILITY ENGINEERING
(1)
INSTYTUT
INFORMATYKI
INNE PODEJŚCIE
Systemy elektroniczne od wielu lat są przedmiotem badań z dziedziny analizy
uszkodzeń i inżynierii niezawodności.
W.G. Ireson, C.F. Coombs, R.Y. Moss: “Handbook of Reliability Engineering and Management”.
McGraw-Hill, New York 1996
M.L. Shooman: “Reliability of Computer Systems and Networks”. McGraw-Hill, New York 1996
Uszkodzenie =
zdarzenie losowe polegające na tym, że przynajmniej jedna cech obiektu przestanie
spełniać wymagania stawiane obiektowi (systemowi).
Zmienność w czasie intensywności uszkodzeń J
1) okres wstępnej eksploatacji (docieranie): J jest funkcją malejącą
2) normalna eksploatacja: J jest stała
3) okres starzenia: stały wzrost J
(2)
INSTYTUT
INFORMATYKI
Niezawodność =
własność obiektu (systemu) mówiąca o tym, czy spełnia on poprawnie wszystkie funkcje
przez wymagany czas w obecności danego zespołu czynników wymuszających.
Za miarę matematyczną niezawodności przyjmuje się prawdopodobieństwo zdarzenia,
że czas pracy bez uszkodzenia jest niemniejszy od założonego (wymaganego) czasu
pracy bez uszkodzenia.
Obiekt może być:
a) elementarny – podstawowy, nienaprawialny komponent
b) złożony – złożony z obiektów elementarnych system o strukturze:
szeregowej
równoległej
uszkodzenie pojedynczego komponentu
powoduje uszkodzenie całego systemu
mieszanej
(3)
INSTYTUT
INFORMATYKI
Parametry charakteryzujące niezawodność
MTTFF (Mean Time To First Failure) – wartość oczekiwana czasu poprawnej
pracy obiektu
np. dla obiektów elementarnych (nienaprawialnych)
gdy J jest stała: MTTFF =
1
J
MTBF (Mean Time Between Failures) – średni czas pomiędzy
uszkodzeniami
np. dla systemów N-elementowych o strukturze szeregowej (system
przechodzi ze stanu sprawności lub niesprawności w wyniku uszkodzenia
jednego z N elementów):
MTBF = MTTFF =
1
NJ
MODELE PRZETWARZANIA
(1)
INSTYTUT
INFORMATYKI
Środowisko rozproszone
Niedeterminizm przetwarzania:
nieznana liczba procesów
nieznana topologia sieci
współbieżność procesów uruchamianych w różnych momentach czasu
i wykonywanych z różnymi prędkościami
niezależne dane wejściowe
niedeterminizm procesorów
nieokreślone opóźnienia komunikacyjne
nieokreślone uporządkowanie wiadomości
zawodność procesów i łącz komunikacyjnych
heterogeniczność elementów
(2)
INSTYTUT
INFORMATYKI
Modele komunikacji
Message Passing
Distributed Shared Memory
easy to implement
hard to program
hard to implement
easy to program
no common memory
LOCAL
MEMORY
SHARED
MEMORY
no global clock
PROCESSOR
PROCESSOR
LOCAL
MEMORY
PROCESSOR
PROCESSOR
(3)
INSTYTUT
INFORMATYKI
Modele systemu
1) system synchroniczny:
kroki algorytmu wykonywane jednocześnie przez wszystkie procesy
(synchronous rounds)
P1
∆t
∆t
∆t
∆t
P2
P3
znane ograniczenia:
prędkości procesorów
opóźnień komunikacyjnych
możliwa synchronizacja zegarów
(4)
INSTYTUT
INFORMATYKI
przykłady:
atomowa (natychmiastowa) komunikacja:
P1
P2
P3
jednostkowe czasy komunikacji
komunikacja poprzez współdzielone zmienne:
− state-reading model
− link-register model
(5)
INSTYTUT
INFORMATYKI
2) system asynchroniczny:
niezależne wykonywanie operacji przez procesy, w różnym tempie,
skończonym, ale nieznanym
opóźnienia komunikacyjne skończone, lecz nieznane
3) system quasi-synchroniczny (timing-based):
ograniczenia względnych prędkości procesów i czasów komunikacji
istnieją, lecz nie są znane
ograniczenia są znane, lecz występują dopiero po nieznanym z góry
czasie
ograniczenia nie są znane i występują dopiero po nieznanym czasie
ograniczenia występują tylko w czasie pewnych nieznanych z góry
okresów (stable periods)
... i 30 innych modeli
(6)
INSTYTUT
INFORMATYKI
Graf połączeń G (communication graph)
distance(i,j) = min. ścieżka między Pi a Pj w G
diameter(G) = max distance(i,j)
i,j
Modele błędów
fail-stop
– defekty w systemie mogą być tylko klasy zatrzymanie
fail-silent – defekty w systemie mogą być tylko klasy upadek
fail-safe
– defekty w systemie mogą być tylko typu łagodnego
(7)
INSTYTUT
INFORMATYKI
Przetwarzanie sterowane zdarzeniami (event-driven)
Procesy:
uporządkowana sekwencja niepodzielnych zdarzeń
czas trwania zdarzenia – przyjmujemy natychmiastowość zdarzeń
stan sik procesu Pi jest zbiorem wartości jego zmiennych lokalnych
Ogólne typy zdarzeń:
init (Pi, sik) – lokalny stan procesu Pi zostaje zainicjowany wartością sik ;
wyróżniamy wirtualne zdarzenie e0=init0(Pi , si0) rozpoczynające
przetwarzanie na procesie Pi
stop (Pi) – Pi kończy działanie
send (Pi, P, m) – Pi wysyła wiadomość m do procesów Pi ∈ P
recv (Pi, Pj, m) – Pi odbiera wiadomość m od procesu Pj
internal (Pi) – Pi zmienia wartości zmiennych lokalnych
fail (Pi) – występuje defekt w procesie Pi
(8)
INSTYTUT
INFORMATYKI
Stan lokalny procesu Pi:
w chwili t jest reprezentowany sekwencją zdarzeń ei0, ei1, ... eit, (zwaną
historią), które zaszły od momentu wystąpienia zdarzenia init0(Pi, si0) do
chwili t
zdarzenia zachodzące na procesie Pi są w pełni uporządkowane
zdarzenia w całym przetwarzaniu rozproszonym są częściowo
uporządkowane relacją poprzedzania → (happen before) [2] określającą
porządek przyczynowy (causal precedence)
stan będący efektem zajścia zdarzenia eik oznaczamy sik
stany procesów są również częściowo uporządkowane następującą relacją
poprzedzania →:
sik → sjl ⇔ eik+1 → ejl lub eik+1 = ejl
(9)
INSTYTUT
INFORMATYKI
Stan globalny systemu rozproszonego
jest wektorem stanów lokalnych procesów i stanów kanałów
komunikacyjnych C = 〈s1t, s2t, ... , snt〉 ∪ 〈... , cijt, ... 〉
stan globalny jest spójny ⇔
1) (e ∈ C ∧ e’ → e ) ⇒ e’ ∈ C
2) e = send (Pi, Pj, m) ∧ e’ = recv (Pj, Pi, m):
(e ∈ C ∧ e’ ∈ C) ⇒ m ∉ C
3) e = send (Pi, Pj, m) ∧ e’ = recv (Pj, Pi, m):
(e ∈ C ∧ e’ ∉ C) ⇒ m ∈ C
4) e = send (Pi, Pj, m): e ∉ C ⇒ m ∉ C
stan globalny jest silnie spójny ⇔ jest spójny oraz
∀ e e’ e = send (Pi, Pj, m) ∧ e’ = recv (Pj, Pi, m): e ∈ C ⇔ e’ ∈ C
AUTOMAT I/O
(1)
INSTYTUT
INFORMATYKI
AUTOMAT I/O
Automat I/O A = 〈 Sig(A), States(A), Start(A), Trans(A), Task(A) 〉
Sig(A)
– sygnatura (zbiór akcji) automatu:
Sig(A) = 〈Input(A), Output(A), Internal(A)〉
actions(A) = Input(A)∪Output(A)∪Internal(A)
external(A) = Input(A)∪Output(A)
locally_controlled(A) = Internal(A)∪Output(A)
States(A) – niekoniecznie skończony zbiór stanów
Start(A)
– niepusty zbiór stanów początkowych
Trans(A) – relacja przejść:
Trans(A) ⊆ States(A) × Sig(A) × States(A)
∀s∈States(A) ∀a∈Input(A) ∃s’∈States(A): (s, a, s’)∈Trans(A)
Task(A)
– podzbiory (klasy) akcji automatu kontrolowanych
lokalnie (locally_controlled(A))
akcja a jest
dopuszczalna
w stanie s
AUTOMAT I/O
(2)
INSTYTUT
INFORMATYKI
Przykład automatu
Clock
Sig:
IN: request
States:
counter∈N, początkowo := 0;
flag: Boolean, początkowo := false;
Trans:
tick
Precondition:
true
Effect:
counter++
Task:
OUT: return(t), t∈N
request
Effect:
flag:=true
INTERNAL: tick
return(t)
Precondition:
flag==true
counter==t
Effect:
flag:=false
{ tick }
{ return(t): t∈N }
AUTOMAT I/O
(3)
INSTYTUT
INFORMATYKI
Poprawność wykonania automatu A
Wykonanie α automatu A jest poprawne
jeżeli dla każdej klasy C operacji z Task(A):
1. jeśli α jest skończone, to C nie jest dopuszczalne w stanie końcowym wykonania α
2. jeśli α jest nieskończone, to
a) α zawiera nieskończenie wiele zdarzeń z C albo
b) nieskończenie wiele wystąpień stanów, w których C nie jest dopuszczalne
Przykład dla Clock
poprawne wykonania:
tick, tick, tick, ...
tick, tick, request, tick, tick, return(4), tick, tick, ...
niepoprawne wykonania:
tick, tick, tick
tick, tick, request, tick, tick, tick, ...
KANAŁY KOMUNIKACYJNE
(1)
INSTYTUT
INFORMATYKI
Automat Channel Cij
Sig:
IN: send(m)ij m∈M
States:
Q: kolejka FIFO elementów z M, początkowo := ∅;
Trans:
send(m)ij
Effect:
Q := Q ∪ {m}
Task:
{ recv(m)ij m∈M }
OUT: recv(m)ij m∈M
recv(m)ij
Precondition:
m jest na początku Q
Effect:
Q := Q \ {m}
(2)
INSTYTUT
INFORMATYKI
Cause function
There exists a function cause mapping each receive event in execution β to a preceding send
event in execution β such that:
1. for every receive event ε, ε and cause(ε) contain the same message argument
2. cause is surjective (onto)
3. cause is injective (one-to-one)
4. cause prevents order, that is, there do not exist receive events ε1 and ε2 with ε1 preceding
ε2 in execution β and cause(ε2) preceding cause(ε1) in execution β
The cause function is a tool for identifying which send event “causes” each receive event.
First condition says that only correct messages are delivered, second one ensures that
messages are not lost, third condition prevents duplication of events and the last one says
that they are not reordered [2].
(3)
INSTYTUT
INFORMATYKI
Osłabiamy własności funkcji cause:
Strong loss limitation (SLL)
If there are infinitely many send(m) events in β execution (for any particular m), then
there are infinitely many send(m) events in the range of the cause function.
Weak loss limitation (WLL)
If there are infinitely many send events in execution β, then the range of the cause
function is infinite.
Finite duplication (FDp)
The cause function maps only finitely many receive events to any particular send
event.
TYPY KANAŁÓW
(1)
INSTYTUT
INFORMATYKI
TYPY KANAŁÓW
reliable FIFO channel
zachowanie tego kanału opisuje funkcja cause
reliable reordering channel
zachowuje semantykę exactly-once delivery, bez uporządkowania zdarzeń (funkcja
cause bez warunku 4)
Sig:
IN: send(m)ij m∈M
States:
C: zbiór elementów z M, początkowo := ∅;
Trans:
send(m)ij
Effect:
C := C ∪{m}
OUT: recv(m)ij m∈M
recv(m)ij
Precondition:
m∈C
Effect:
C := C \ {m}
TYPY KANAŁÓW
(2)
INSTYTUT
INFORMATYKI
unreliable channel
dopuszcza zagubienie i / lub powielenie wiadomości (funkcja cause bez warunku 3 lub
bez 3 i 4); np.
losing FIFO channel = WLL + FDp + uporządkowanie
States:
Q: kolejka FIFO elementów z M, początkowo := ∅;
Trans:
send(m)ij
Effect:
Q := Q ∪ [{m}∪...∪{m}]
(skończona liczba kopii ≥0)
recv(m)ij
Precondition:
m jest na początku Q
Effect:
Q := Q \ {m}
losing reordering channel = WLL + FDp + brak uporządkowania
States:
C: zbiór z powtórzeniami elementów z M, początkowo := ∅;
Trans:
send(m)ij
Effect:
C := C ∪{m}∪...∪{m}
(skończona liczba kopii ≥0)
recv(m)ij
Precondition:
m∈C
Effect:
C := C \ {m}
RESILIENCE
(1)
INSTYTUT
INFORMATYKI
RESILIENCE
Def.: A f-crash fair execution of N processes is an execution which is correct
on at least N - f processes (i.e. at least N - f processes is correct).
Def.: The maximal number of faulty processes that can be handled by an
algorithm is called the resilience of the algorithm.
FAULT TOLERANCE
(1)
INSTYTUT
INFORMATYKI
TOLEROWANIE USZKODZEŃ
(FAULT TOLERANCE)
Fault Tolerance
masking (of failures)
nonmasking
def: even in the presence of
faults the system
continues to satisfy its
input/output relation
def: input/output relation is
violated temporarily and
the system is guaranteed
to resume it eventually
(well-defined failure behavior)
comfortable and costly
when masking is:
impossible (e.g. consensus)
impractical (e.g. amount of redundancy)
unnecessary
FAULT TOLERANCE
(2)
INSTYTUT
INFORMATYKI
Fault Tolerance
masking
techniques:
redundancy
(error correction codes,
replication,
voting)
broadcasts
agreement
nonmasking
techniques:
checkpointing & recovery
FAULT TOLERANCE
(3)
INSTYTUT
INFORMATYKI
FURTHER TOPICS IN FOCUS
FAULT
TOLERANCE
ROBUST ALG.
STABILIZATION
REPLICATION
each step of each process is
taken with sufficient care to
ensure that correct processes
take correct steps in spite of
failures
LITERATURA
(1)
INSTYTUT
INFORMATYKI
LITERATURA
[1]
Jean-Claude Laprie ed. “Dependability: Basic Concepts and Terminology”. Dependable
Computing end Fault Tolerant Systems, vol.5, Springer-Verlag, Wien - New York 1991;
tłumaczenie:
Stanisław J. Piestrak. „Wiarygodność: Pojęcia podstawowe i terminologia”. EDCC-2
Companion Workshop on Dependable Computing, Politechnika Śląska, Gliwice 1996.
[2] Lamport L. (1978), “Time, clocks, and the ordering of events in a distributed system”,
Communication of the ACM, vol. 21, no. 7, pp. 558–565
[3]
N. A. Lynch. “Distributed Algorithms”. Morgan Kaufmann Pub. Inc., San Francisco 1996.
[4]
Gerard Tel, “Introduction to Distributed Algorithms”. Cambridge University Press, 1994.

System wiarygodny

Transkrypt

Podobne dokumenty

Przegląd prezentacji (materiał wprowadzający): „Klikamy” w menu

W DNIU 6 i 7 MARCA W KLUBIE ODBĘDZIE SIĘ KOMPUTEROWE

La laďcité w kryzysie. Francuski model świeckości państwa wobec

Klaster ekoenergetyczny (Niemcy)

Plakat o warsztatach

Wskazówka Umiejętność wywierania wpływu jest być może

Program - Forum Rewitalizacji

Nowy Sącz, dn - Kasacja i demontaż pojazdów Ptak Nowy Sącz

Pytania specjalnościowe - Aplikacje internetowe i systemy