Recovery-Oriented Computing

Recovery-OrientedComputing Aspekte und Werkzeuge der Datenbankadministration und deren Automatisierung Mario Eckhardt

Einleitung • Motivation • Ziele des Recovery-Oriented Computing • Peres` Gesetz • Techniken des Recovery-Oriented Computing • Redundanz und Isolation • Rekursive Neustarts • Selbsttest und Verifikation im laufenden Betrieb • Unterstützung zur Problemdiagnose • Reversible Systeme • ROC in Forschungs- und Anwendungssystemen • ROC-Techniken in DBMS • Mercury Satellitensystem • Pinpoint • ROC-1: ROC auf Hardwareebene • Undofähiges E-mail-System • Zusammenfassung

Motivation • Downtime Kosten (pro Stunde) • Brokerage operations $6,450,000 • Credit card authorization $2,600,000 • Ebay $225,000 • Amazon.com $180,000 • Package shipping services $150,000 • Home shopping channel $113,000 • Catalog sales center $90,000 • Airline reservation center $89,000 Quellen: T. Sweeney. No Time for DOWNTIME – IT Managers feel the heat to prevent outages that can cost millions of dollars. Internet Week, n. 807, 3 April 2000 Kembel, R. Fibre Channel: A Comprehensive Introduction, p.8, 2000.

Motivation MTTF MTTF ______ ____________ ? Verfügbarkeit = = > 99.999% MTBF MTTF + MTTR Fehler Fehler MTTR MTTF MTBF MTBF: Mean Time between Failure MTTF: Mean Time to Failure MTTR: Mean Time to Repair Verfügbar Downtime

Fehler sind unvermeidbar • Wachsende Komplexität und zunehmende Verknüpfungen in modernen Systemen • Zeitdruck durch rasche Innovationen, kurze Entwicklungs- und Testzeiten • Zwang zur Kostenreduktion • Skaleneffekt • „Irren ist menschlich“

Ironie der Automation • Automation kein Gegenmittel bei menschlichen Fehlern • Anforderung an Fehlerfreiheit vom Operator zum Programmierer verschoben • Automatisierte Systeme vermeiden Interaktion mit Operator • Weiterhin manuelle Bearbeitung komplexer, seltener Aufgaben • Operator überfordert, wegen fehlender Praxis im komplexen System

Ziele des ROC • Verfügbarkeit steigern durch Verkürzung der durchschnittlichen Reparaturdauer • Total Costs of Ownership (Kosten für Anschaffung und laufenden Betrieb) verringern MTTF MTTF ______ ____________ Verfügbarkeit = = MTBF MTTF + MTTR MTTR

„If a problem has no solution, it may not be a problem, but a fact, not to be solved, but to be coped with over time“ – Shimon Peres

Konsequenz aus Peres` Gesetz • Fehler als Fakten akzeptieren • Mentalität für Fehlerbehebung statt Fehlervermeidung • Entwicklung von Techniken zur schnelleren Fehlererkennung und -behebung, um Fehlern gewachsen zu sein „If a problem has no solution, it may not be a problem, but a fact, not to be solved, but to be coped with over time“

Redundanz und Isolation • Redundanz • Zusätzliche Software- und Hardwarekomponenten, sowie zusätzliche Verbindungen zwischen den Komponenten • Datenkopien • Vermeidung eines „single point of failure“

Redundanz und Isolation • Isolation • Partitionierung im System, mehrere Komponenten bilden Partition • Partitionen beeinflussen sich nicht untereinander • Fehler auf Partition begrenzen, Verbreitung verhindern • Inkrementeller Systemupgrade, Komponentenaustausch ohne System herunterzufahren, Trainings- und Testsystem auf eigener Partition

Rekursive Neustarts • Vorteile von Neustarts: • Behebung von Heisenbugs • Rückführung in bekannten und ausgiebig getesteten Zustand • Vorteile von Neustarts auf mehreren Ebenen (Rekursive Neustarts), feine Partitionierung vorausgesetzt: • Erhöhte Fehlertoleranz • Verringerung der MTTR des Systems • Zwei Ansätze: • Wiederbelebung: Neustart fehlerhafter Komponenten • Verjüngung: prophylaktischer Neustart funktionierender Komponenten

Selbsttest und Verifikation im laufenden Betrieb • Erkennen latenter Soft- und Hardwarefehler • Test der Fehlerbehandlungs- und Recoveryprozeduren • Test der konkreten Zusammenstellung von Anwendungen, Betriebssystem, Treibern und Hardware beim Benutzer vor Ort • Fehlerinjektion zur Operatorschulung

Unterstützung zur Problemdiagnose • Fehler nicht verbergen • Interfaces für Fehlerberichte an allen Komponenten • Fehlerinformationen im ganzen System bekannt machen • Logging von Fehlern • Früherkennung von Fehlern • Unterstützung der Fehleranalyse ex post

Reversible Systeme • Umsetzung des Undo-Konzepts auf Systemebene • Unterstützung menschlichen Vorgehens bei Fehlerbehebung • Trial & Error • Retroaktive Reparatur (3R Undo)

3R Undo: Rewind, Repair, Replay • Rewind • Systemzustand (Benutzer-, Anwendungs- und Betriebssystemdaten) auf früheren Zeitpunkt zurücksetzen • Repair • Änderungen am System durch den Operator oder Unterlassen einer Aktion • Replay • Undo-System führt alle Endbenutzer-Interaktionen, im übersprungenen Zeitraum, nochmals aus

3R Undo: Rewind, Repair, Replay • Tracking • Erfassung der Intention bei Benutzerinteraktionen, kein Tracking der Reparaturschritte • über verbenbasierte Protokolle • Externe Inkonsistenzen • Kompensation • Undo über Systemgrenzen ausdehnen • Ignorieren • Feingliederung des Undo • Verschiedene Zeitlinien • Abhängigkeiten zwischen zu trackenden Daten (shared state)

3R Undo Systemarchitektur Control UI User verbs Undo Manager Timeline Log Undo Proxy • Service Application • user state • application • OS control Verben-Fluss Verbenfluss beim Replay Time-travel Storage

Aktueller Forschungs- und Entwicklungsstand • Prototypen auf Soft- und Hardwareebene • Viele Ansätze mit Teilen der ROC-Philosophie bereits existent • Weitere anwendungsbezogene Forschung nötig • Erfolg von recovery-oriented Soft- und Hardware auf dem Markt bleibt abzuwarten

ROC-Techniken in DBMS • Transaktionen mit ACID-Eigenschaften • Logging • Sicherungspunkte • Backups

Mercury Satellitensystem • Bodenstation der Universität von Stanford zur Kommunikation mit Forschungssatelliten • COTS-Technologie (commercial off-the-shelf), Programmiersprache Java, jede Komponente läuft in eigener Java Virtual Machine • Architektur: REC FD Neustarts mbus Fehlererkennung (liveness pings) Communication (TCP/IP) fedrcom ses str rtu

Pinpoint • Anwendungsbereich: große komplexe dynamische Systeme • Zwei automatisierte Phasen • Live Tracing • Data Clustering

ROC-1: ROC auf Hardwareebene • Hoch verfügbares Clustersystem für Internet Server Anwendungen • Aufbau: • 64 Knoten (bricks) • Pentium-II-Mobile-Prozessor (266MHz) • 18 GB Festplatte • 256 MB fehler korrigierendes DRAM • 4 redundante 100 Mb/s-Netzwerkkarten • 18MHz-Motorola-Diagnoseprozessor • 16 First-Level-Switches • 2 Gigabit-Switches

ROC-1: ROC auf Hardwareebene • Höheres Prozessor/Festplatte-Verhältnis • Diagnose Subsystem • Angewandte ROC-Techniken: • Redundanz und Isolation • Selbsttest und Verifikation im laufenden Betrieb • Unterstützung zur Problemdiagnose • Design für Interaktion mit Mensch

Undo-fähiges E-mail-System • Prototyp der Universität von Berkeley • SMTP und erweitertes IMAP-Protokoll • Overhead • Geringfügig längere Sessions • Zusätzlicher Speicherbedarf • Performance • Rewind: etwa 590 Sekunden für System mit 10000 Benutzern • Replay: 8,8 Verben pro Sekunde

Zusammenfassung • Integration des Menschen in den Recovery-Prozess? • ROC als neuer Grundsatz für die Entwicklung von Anwendungssystemen? • Schnelle Reparatur – (k)ein Freibrief für fehlerhafte Software?

Recovery-Oriented Computing