Ü b e rs ic h t • Z ie le • D e fi n it io n d e r V e rf ü g b a rk e it • R O C i n D B M S • F e h le rk la s s e n • R O C -T e c h n ik e n • R O C -B a u s te in e • K o s te n /N u tz e n • F a z it

R e c o v e ry R e c o v e ry - - o ri e n te d c o m p u ti n g ( R O C o ri e n te d c o m p u ti n g ( R O C D a te n b a n k e n u n d I n fo rm a ti o n s s y s te m

Technische Universität Kaiserslau Lehrgebiet Datenverwaltungssyste Wintersemester 2005/2 Benjamin Mo

2

M o ti v a ti o n • "I f a p ro b le m h a s n o s o lu ti o n , it m a y n o t b e a p ro b le m , b u t a f a c t - n o t to b e s o lv e d , b u t to b e c o p e d w it h o v e r ti m e .“

(Shimon Peres, israelischerPolitiker)

F e h le r in C o m p u te rs y s te m e n s in d u n v e rm e id b a r F e h le r to le ri e re n o d e r k o m p e n s ie re n

Ü b e rs ic h t • Z ie le • D e fi n it io n d e r V e rf ü g b a rk e it • R O C i n D B M S • F e h le rk la s s e n • R O C -T e c h n ik e n • R O C -B a u s te in e • K o s te n /N u tz e n • F a z it

4

Z ie le • Z ie le v o n R O C : – E rh ö h u n g d e r V e rf ü g b a rk e it – V e rr in g e ru n g d e r to ta l c o s ts o f o w n e rs h ip

(Anschaffungskosten+ KostenfürlaufendenBetrieb) –Verbesserungder Administrierbarkeit –Trainingssystem

V e rf ü g b a rk e it

t MTTRMTTF MTBF SystemstartCrashRecovery beendetCrashRecovery beendet

MTTRMTTF

MTTF MTBF

MTTF eitVerfügbark +== MTTR = mean time to repair MTTF = mean time to failure MTBF = mean time between

MTTF

6

R O C i n D a te n b a n k m a n a g e m e n ts y s te m e n • A C ID -E ig e n s c h a ft e n w e rd e n g e fo rd e rt • Im F e h le rf a ll: j ü n g s te r tr a n s a k ti o n s k o n s is te n te r Z u s ta n d w ie d e rh e rs te lle n • S a m m lu n g r e d u n d a n te r D a te n i m N o rm a lb e tr ie b

–Protokollierung von Aktionen (Logging) –Anlegen von Sicherungspunkten

F e h le rk la s s e n • T ra n s a k ti o n s fe h le r

–Fehlerin Anwendung, Deadlock

• S y s te m fe h le r

–Fehlerin Systemsoftware, Stromausfall, menschlicheFehlbedienung

• P la tt e n fe h le r

–Datenverlustim Festspeicher

• K a ta s tr o p h e n - E rd b e b e n , Ü b e rs c h w e m m u n g e n , F e u e

( )

8

R O C -T e c h n ik e n • M o d u la ri s ie ru n g

–Java Virtual Machine simuliertkomplettes System –unabhängige und eigenständige Komponenten

• R e d u n d a n z

–KeinSingle point of failure –zusätzliche Festplatten, Lüfter, Netzwerkkarten … –Cluster-Systeme

R O C -B a u s te in e • R e k u rs iv e N e u s ta rt s

–vorallemfürJava-Umgebunginteressant –TatsächlicheAnwendungin Praxis: Mercury Satelliten-Projekt

• U n d o a u f S y s te m e b e n e

–Wiederherstellenvon Sicherungspunkten –Besonderheit: Replay-Schritt

• R O C a u f H a rd w a re b e n e : R O C -1

–BishernurPrototyp –VölligandererAnsatzalsandereBausteine

10

R e k u rs iv e N e u s ta rt s

•Viele Fehler lassen sich durch Neustart beheben –Systeme nicht auf solches Vorgehen ausgelegt •Idee: Neustarts auf verschiedenen Ebenen (Recursive Restartability) •Granularität: System, Teilsystem, Komponenten •Zwei Ansätze: –Neustarts fehlerhafter Komponenten zur Fehlerbehebung –periodische Neustarts fehlerfrei laufender Komponenten zur Verjüngung

N e u s ta rt -B ä u m e • K o n v e n ti o n e lle s S y s te m

–Komponenten können nur gemeinsam neu gestartet werden ABCD

R ABC AB

R AR BC R B

• S y s te m m it R e c u rs iv e R e s ta rt a b ili ty

–Komponenten könne einzeln und in Grupp gestartet werden MTTR system≥max(MTTR komponenten)

12

B e is p ie l fü r R R : M e rc u ry -B o d e n s ta ti o n

•Kommunikation mit Satelliten –Datenübertragung nur in bestimmtem Winkel möglich (vier mal täglich für 15min) •Aufbau aus kostengünstigen „commercialoff-the- shelfComponents“ –Jede Komponente läuft in eigener Java Virtual Machine –Fehlerbeseitigung durch Administratoren durch einfaches Neustarten des Systems

B e is p ie l fü r R R : M e rc u ry -B o d e n s ta ti o n

•Fehlererkennung durch Pings(„areyoualive?“) –Einfach zu realisieren –Fehlererkennung wird automatisiert und benötigt keinen Administrator mehr •Komponenten –lose gekoppelt •Keine Änderungen am eigentlichen Code nötig –Feine Granularität <-> viele Interfaces –Kosten für Neustrukturierung <-> Kosten für Ausfälle

14

E n tw ic k lu n g e in e s N e u s ta rt -B a u m s

205

V e rb e s s e ru n g d u rc h r e k u rs iv e N e u s ta rt • B is z u s e c h s fa c h e V e rb e s s e ru n g d e r M T T R b e i e in z e ln e n K o m p o n e n te n • E tw a v ie rf a c h e V e rb e s s e ru n g d e r M T T R fü r d a s G e s a m ts y s te m

5,86,121,954,7MTTR nachher in s

28,928,928,928,928,9MTTR vorher in s

5h5h1 Monat10min1 MonatMTTF

istuise/istrpbcomfedrmsgboneKomponenten:

16

U n d o a u f S y s te m e b e n e • A d m in is tr ie ru n g s fe h le r n ic h t a u s s c h lie ß b a r • A u to m a ti s ie ru n g s ir o n ie

–AutomatischeBehebungleichterFehler –TrainingseffektfürAdministratorengehtverloren –SchlechtererUmgangmitschwerenFehlern

• U n te rs tü tz t V e rs u c h s -u n d -I rr tu m s -M e th o d e

U n d o a u f S y s te m e b e n e : S c h e m a

•Proxy: hört Benutzeroperationen mit •Zeitreisespeicher: Zustandsschnappschüsse •Log: Speicherung der Intention der Benutzeraktion •Undo-Manager: Herzstück und Koordinator

Proxy Applikation

Undo- Manager

UIBenutzer Zeitreise- speicher

ord ko ert ini

18

R e w in d -S c h ri tt • D re i S c h ri tt e : 3 R ‘s :

–Rewind –Repair –Replay

• R e w in d -S c h ri tt

–ähnlich Rollback in DBMS –Wiederherstellen eines Zustands aus Zeitreisespeicher

Proxy Applikation

Undo- Manager

UIBenutzer Zeitreise- speicher

Log für Zeitlinien

ord ko ert ini

R e p a ir -S c h ri tt • D re i S c h ri tt e : 3 R ‘s :

–Rewind –Repair –Replay

• R e p a ir -S c h ri tt

–Änderungen oder Reparaturen vornehmen –Aktion unterlassen

Proxy Applikation

Undo- Manager

UIBenutzer Zeitreise- speicher

ord ko ert ini

20

R e p la y -S c h ri tt • D re i S c h ri tt e : 3 R ‘s :

–Rewind –Repair –Replay

• R e p la y -S c h ri tt

–Wiederholen aller Benutzeraktionen

Proxy Applikation

Undo- Manager

UIBenutzer Zeitreise- speicher

Log für Zeitlinien

ord ko ert ini

B e is p ie l fü r U n d o a u f S y s te m e b e n e A c h tu n g : „ e tw a s “ u n w is s e n s c h a ft lic h !

Marty McFlyDoc B DeLorean

22

R e w in d • A u fb ru c h z u r Z e it re is e ( R e w in d -S c h ri tt )

R e p a ir • V e rä n d e ru n g i n d e r V e rg a n g e n h e it ( R e p a ir -S c h ri tt )

24

R e p la y • R ü c k k e h r in d ie G e g e n w a rt ( R e p la y -S c h ri tt )

U n d o a u f S y s te m e b e n e : P ro b le m e • P ro b le m e :

–Externe Konsistenz –Kein Logging der Intention der Reparaturen möglich, deshalb auch kein Wiederherstellen f diese –Einschränkung der Benutzeraktionen auf festgelegtes Protokoll –Regelwerk für Vorrang verschiedener Undos (Administrator, Benutzer …)

26

R O C -1

•64 Knoten –266MHz-Pentium-II-Mobile-Prozessor –18GB-SCSI-Festplatte –256MB fehlerkorrigierendesDRAM –vier redundante 100Mb/s-Netzwerkkarten –18MHz-Motorola-Diagnoseprozessor •16 First-Level-Switches •zwei Gigabit-Switches •Gesamtspeicherkapazität : 1,2TB •passt in drei Racks

R O C -1 II

•Unterschiede zu „normalen“Clustern –Verhältnis von Festplatte zu CPU: 1/1 –billigere und stromsparendere Prozessoren –Zusammenschluss mit einem Diagnosesystem •ROC-Techniken –physische Isolation –Redundanz –Selbsttest und Verifikation –Verbesserung der menschlichen Interaktion mit de System

28

K o s te n /N u tz e n • K e in e p e rf e k te L ö s u n g m ö g lic h !

Undo auf Systemebene

fallweise manuelle Reparatur Microreboot

Reboot behobene Fehler

Kosten

F a z it

•Bisherige Entwicklung und Forschung hauptsächlich zur Verbesserung der Verfügbarkeit durch Erhöhung der MTTF –Wirksameres Marketing? –Jetzt mehr Potenzial für ROC? •Fehlerhafte Software zu entwickeln ist okay? •Nur Kombination verschiedener ROC-Baustein in Verbindung mit guter Software bringt wirklich Verbesserung der Verfügbarkeit