Selbstheilende Systeme

Transcription

UNIVERSITÄT PADERBORN
Die Universität der Informationsgesellschaft
Selbstheilende
Systeme
Seminar: Autonomic Computing
Frank Nillies - frank@upb.de
Gliederung
Motivation
Definition: Selbstheilung vs. Fehlertoleranz

Selbstheilung
in 4 Phasen

Formale Methoden

Beispiele und Ausblick
IBM

/ Microsoft Framework
Fazit / Literatur
Autonomic/Organic Computing - Thema: Selbstheilung
2
Motivation

75% - 90% aller IT Kosten entfallen auf
Wartung und Reparatur

Computernetze werden immer komplexer

Jeder PC/System ist anders konfiguriert

Fehlertolerante/Sicherheitskritische
Systeme sind bereits im Einsatz
3
Fehlertoleranz vs. Selbstheilung
DIN/ISO
4
Fehlertoleranz vs. Selbstheilung

Systeme für spezielle
Anwendungsgebiete
entwickelt

Beliebige Hardware –
Software Kombination

100% Erhalt der
Spezifikationen
Kein Ausfall des
Systems erlaubt
Realisierung durch
redundante
Hardware

Grundfunktionalität
gewährleisten
Systemausfall soll
minimiert werden
Wartungsaufwand
reduzieren

5
Definition Selbstheilung

Selbstheilung verwendet bei einem Fehler
einen Teil seiner Ressourcen dazu, den Fehler
Schritt für Schritt zu beheben;
Fehlertoleranz hingegen versucht trotz eines
Fehlers die Spezifikationen zu 100% zu erfüllen
Fehlertolerante Systeme können nur auf Fehler
reagieren, die während der Designphase
berücksichtig worden sind;
Ein selbst-heildendes System passt sich
dynamisch und lernfähig seiner Umgebung an.
6
Selbstheilung in 4 Phasen
Kontextbewusstsein
1.
Fehlererkennung

2.
Schadensabschätzung

3.
Wo ist der Fehler aufgetreten?
Welche Teile sind betroffen?
Wiederherstellung

4.
Was für ein Fehler ist aufgetreten?
Wie wird der Fehler behoben?
Betrieb wiederaufnehmen / fortsetzen

Kann der Betrieb fehlerfrei fortgesetzt
werden?
7
1. Fehlererkennung
Problematik:
Was
ist ein Fehler?
Wie erkennt man Fehler?
Lösung:
Redundante
Informationen
Logbücher
Neuronale
Netze
Trainiertes Verhalten
8
1. Fehlererkennung
Funktionsüberprüfung, Konsistenzprüfung

RAM Self Test

Scandisk

Checksummen

ParityBit
9
1. Fehlererkennung
Signalabgleich, Harwareüberwachung

S.M.A.R.T.
Überwachung bei HDDs

Temperatursensoren in
CPUs

Spannungsüberwachung

Netzwerkkabeltest
10
2. Ursachenforschung
Problematik:
Wo
ist der Fehler aufgetreten?
Welche Systemeinheiten sind betroffen?
Lösung:
Funktionsprüfung
BlackBox
Prinzip
11
2. Schadensabschätzung

Kann das System nach dem Fehler den Betrieb
wieder aufnehmen oder treten Folgefehler auf?
Predefined
Failure semantics
Vordefinierte Systemroutinen bei Ausfällen
Hazard analysis
Besteht Gefahr für Personen oder Equipment?
Severity analysis
Wie ernst ist der Fehler für den Folgebetrieb?

Eher bekannt aus der Fehlertoleranz,
Einsatz je nach Anwendungsgebiet.
12
3. Wiederherstellung

Backward recovery:
Einen vorherigen, fehlerfreien Systemzustand
wieder herstellen. Beispielsweise durch Image
Dateien.

Forward recovery:
Einen neuen, fehlerfreien Systemzustand
herstellen.
Beispielsweise durch Rücksetzen von
Datenleitungen oder Neustart.
13
4. Betrieb fortsetzen

Betrieb läuft weiter, die betroffenen
Komponenten sind aber nicht nutzbar.

Benutzer sollte idealerweise von dem Fehler
nichts bemerken, ggf. wird der Administrator
per eMail oder Logfile informiert.

Problem: Folgefehler müssen erkannt
und ebenfalls behandelt werden.
14
Gliederung
Motivation

Formale Methoden,
angelehnt an Fehlertoleranz
15
Fehlerer- & Ursachenerkennung

Redundandcy (Redundanz)
Identische
Bausteine sind mehrfach
vorhanden

Diversity (Vielfältigkeit/Mannigfaltigkeit)
Bausteine
mit gleicher Aufgabe sind in
unterschiedlichen Ausführungen vorhanden

Agenten
Intelligente
Systemkomponenten in
Hardware oder Software
16
Redundancy and Diversity

Domain of information:
Redundante
Speicherung der Daten
Sichere Datenstrukturen
Error correcting codes (ECC):
Erkennt
und repariert Bitfehler
Implementierung basiert auf Hamming-Distance
Robust data structure:
Checksummen,
Rückmeldungen, Handshake
17

Domain of space:
Fallbacksysteme
durch Notstrom, Reservesysteme
Redundanz der Hardware (RAID)
Active redundancy:
Parallel
arbeitende Componenten (TMR)
Passive/standby redundancy:
Hot
standby, Ausfallsystem arbeitet im Hintergrund
Cold standby, Notfallsystem startet bei Ausfall
18

Domain of time:
Doppelte
Berechnung durch verschiedene
und unterschiedliche Algorithmen
Multiple calculation:
Mehrere,
verschiedene Algorithmen berechnen ein
Ergebnis bzw. bestätigen Ergebnisse
Repeated messages:
Nachrichten
werden (auf Anfrage) mehrfach versand
19
Hardware Fehlertoleranz

Statische Redundanz
Parallele
Berechnung mit anschließender
Überprüfung von Checksummen

Dynamische Redundanz
Not-
oder Backupsystem vorhanden.
Umschalten zwischen vorhandenen Systemen

Hybride Redundanz
Kombination
aus statischer und
dynamischer Redundanz
20
Statische Redundanz
Multistage TripleModularReduncy (TMR)
arrangement
21
Dynamische Redundanz
N modular standby sparing system
22
Software Fehlertoleranz

Unterscheidung zwischen
Softwarefehler,
vgl. mit Hardwarefehler
Fehler im System, die auf Softwareprobleme
zurückzuführen sind.

Problemstellung:
Kopie
einer Software enthält die selben
Fehler.
Sind unabhängige Entwicklerteams sicherer?
Software kann altern, Zombieprozesse im
Speicher
23
Exception Handling

Fehlerbehandlung an Hand von Exceptions.
Vorteile:
Voter
entfallen in der Software
Dezentrale Fehlerbehandlung in
einzelnen Routinen (ausfallsicher)
Allgemeine Reaktion auf Fehler möglich

Nachteile:
Dezentrale
Fehlerbehandlung behindert Wartbarkeit
Setzt korrekt implementierte Routinen voraus
(Erschwert die Verifikation des Quellcodes)
24
N version Programming

Es existieren N unterschiedliche
Implementierungen einer Routine.

Aus diesen N Routinen werden zufällig M
Routinen ausgewählt und berechnet.

Per Voter wird analog zum TMC das richtige
Ergebnis validiert.
Beispiel: Verschiedene Sortieralgorithmen
25
N version Programming

Vorteile:
Designfehler
werden erkannt
Sichert (M-1)/2 Fehler ab

Nachteile:
Hohe
Entwicklungskosten durch viele Entwickler
Leistungseinbußen durch viele parallele, bzw.
sequenzielle Berechnungen
Gemeinsame Fehler nicht ausgeschlossen
26
Recovery Blocks

Vor jeder Routine werden Rüchsprungpunkte,
bzw. Backups der Laufzeitumgebung angelegt

Berechnet die Routine ein falsches Ergebnis,
bzw. führt die Berechnung zum Fehlverhalten,
wird der alte Zustand wieder hergestellt.

Die Berechnung wird dann von einer anderen
Routine übernommen.
27
Recovery Blocks

Vorteile:
Kein
Voter benötigt
Kurzzeitige Hardwareausfälle können
behandelt werden
Unterteilung in Subroutinen möglich

Nachteile:
Benötigt
zusätzlichen Speicher und
Akzeptanzberechnungen (schwer zu
implementieren)
Zeitverlust durch Rücksprung (Realtime Systeme?)
28
Gliederung
Motivation
Formale Methoden

Beispiele und Ausblick, Fazit
29
Beispiele

Grid Computing:

IBM Grid
Apple Xgrid
Intel LESC
Sun N1 Grid Engine
…
Eclipse SDK
VisualStudio SDK
IBM Trivoli
IBM Rejuvention
…
30
Beispiele

RAID Systeme

FPGAs
Xilinx

LoadBalancer

Managed Network
Cisco
31
Realität und Vision – Ausblick
Woran wird geforscht:
Was ist real:

Selbstheilung, angelehnt an Fehlertoleranztechniken
Überwachung der
Systeme
Kooperation mit dem
Benutzer, Administrator oder Entwickler

Intelligente Integration
Kontextbewusstsein
Integration bereits auf
Compilerebene
Interoperable
Hardware
…
32
Fazit
Probleme:
Vorteile:

Geringere Kosten

Weniger Ausfälle

Einfachere
Integration

Kaum detaillierte
Informationen
verfügbar

IBM derzeit als de
fakto Monopolist
33
Literatur

Neil Storey: Safety-Critical Computer
Systems, Prentice Hall 1996

IBM Research Center:
http://www-128.ibm.com/developerworks/autonomic/
Workshop on Selfhealing Systems 2002
Workshop on Selfhealing Systems 2004

34
Fragen ?
Vielen Dank für eure Aufmerksamkeit.
35
Autonomic Computing
The Vision of Autonomic Computing, Watson Research Center, IEEE 2003
36
Speiseplan Palmgarten
Guten Appetit.
37
Hybride Redundanz
N modular
redundancy
with spares
38