• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Präsentation Monitoring 31.1.2011
 

Präsentation Monitoring 31.1.2011

on

  • 754 views

 

Statistics

Views

Total Views
754
Views on SlideShare
754
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Präsentation Monitoring 31.1.2011 Präsentation Monitoring 31.1.2011 Presentation Transcript

    • Monitoring Distributed Real-Time Systems:A Survey and Future Directions Maik Heller MAI3 2010 16.12.2010 1
    • Gliederung• 1.Problemstellung – Airbus 330 Flugsystem• 2.Begriffsdefinitionen und Grundlagen• 3.Monitore: Einführung und Forschungsstand• 4.Monitor-Architekturen für verteilte Echtzeitsysteme• 5. Wichtige zu überwachende Eigenschaften im Monitoring• 6.Zusammenfassung und Ausblick 2
    • 1.Problemstellung – Airbus 330 Flugsystem ADR: Air Data Reference (Höhe, Geschwindigkeit) Air Data Inertial Reference Units Inertial Reference (IR) (Flugbahn, GPS) Flugcomputer 3 PRIMS ADRIU 1 scheiterte:-3 primäre Flugcomputer (PRIMS 1-3) -> Einer ist Master Computer akzeptierteVorfall: Fehlerverhalten eines Master: Wechsel von PRIM 1 zu 2 aber korrupte Daten:-PRIM 3 zeigt Fehler an: Crew schaltet von ADRIU 1 zu 3 ->System scheiterteWeiteres Fehlverhalten : Wechsel von PRIM 2 zu 1 ->Kein Switchen 3-Durch Fehlverhalten manuelle Flugkontrolle ->Notlandung möglich
    • 2.Begriffsdefinitionen und Grundlagen• 2.1 Echtzeitsysteme• 2.2 Verteilte Echtzeitsysteme• 2.3 Konzepte für fehlertolerante Systeme 4
    • 2.1 Echtzeitsysteme (Real-time Systems)• Ein Echtzeitsystem ist ein beliebiges System, bei welchem die Zeit, zu der ein Output als Reaktion auf einen Input erfolgt, von Wichtigkeit ist.• Das Intervall zwischen Input-Zeit und Output -Zeit muss dabei hinreichend klein sein, um eine akzeptierbare Pünktlichkeit zu erzielen. 5
    • 2.1 Echtzeitsysteme (Intervallabhängigkeit)-> Output ist nur korrekt, wenn er auch zu einem korrekten Zeitpunkt erfolgt !Unterscheidung in:• Weiche Echtzeitsysteme: – Die Ergebnisse von weichen Echtzeittasks sind nach der Deadline weiterhin von Nutzen. Verursachen keinen Schaden. – > z.B. Videostreaming mit Performanceeinbrüchen (Bildfehler)• Harte Echtzeitsysteme: – Eine Überschreitung der Antwortzeit wird als ein Fehler gewertet. Führt zum Scheitern des Systems. – > z.B. Sicherheitskritisches System (Reaktor, Shuttle) 6
    • 2.2 Verteilte Echtzeitsysteme• In einem verteilten Echtzeitsystem besteht das Berechnungs-Cluster aus mehreren Echtzeitcomputersystemen (Knoten), die über ein Echtzeit- Kommunikationssystem verbunden sind.• Antwortzeiten (Deadlines) des Kommunikationssystems 7 müssen zusätzlich eingehalten werden!
    • 2.2 Verteilte Echtzeitsysteme – Bsp. Flugzeug 8
    • 2.3 Konzepte für fehlertolerante Systeme• In einem verteilten Echtzeitsystem können Fehler auftreten -Verlust einer Nachricht -Fehlerhafte Nachricht Ausfall eines Knotens / Komponente ->Fehler einer Komponente (fault) liefert Fehlerzustand (error) und führt zu einem Fehlverhalten des gesamten Systems (failure)• Fehlertoleranz: – Hard- und Software-Fehler sollten das Echtzeitsystem nicht zum Totalausfall führen• Fehlerentdeckung: – Wissen über das korrekte Verhalten der Berechnung – Vergleich von zwei redundanten Kanälen (Pilot / Co-Pilot) 9
    • 2.3 Konzepte für fehlertolerante Systeme• Eindämmungsbereiche: Fault-Containment Region (abk. FCR) – Fehler in Knoten (faults) sollen eingedämmt werden – Methode: physikalische Trennung der FCR, aber: • Kommunizieren über gemeinsame Kanäle • elektromagnetische Strahlung kann Funktion beeinträchtigen• Einstufen von Fehlern nach Hybrid fault model (Thambiduarai, Park) • Strukturierte Sammlung von Informationen, Probleme und Konsequenzen – Basiert auf versendete Nachrichten von anderen Knoten – Gutartiger Knoten: Versendet fehlerfreie Nachrichten (pass CRC-Check) – Synchronisierte Systeme: Nachrichten zu unerwarteten Zeiten auch gut – Symmetrischer Knoten: Gleiche Nachrichten zu jedem Empfänger, N. beliebig – Asymmetrischer Knoten(byzantinisch): Unterschiedliche Nachrichten zu unterschiedlichen Empfängern, 1 Botschaft nicht fehlerhaft• Maximal fault assumption: MFA (NASA´s SPIDER, basiert auf HFM) • Max Art, Anzahl und Empfangsrate von Fehlern für jeden FCR unter denen System funktionieren soll • Statistisches Modell: Zuverlässigkeit der Hardware, Umwelt, weitere Faktoren 10 • Flugverkehr:10 -9 Fehler pro Betriebsstunde -> sonst Gefahr
    • 3. Monitoring: Einführung und Forschungsstand• 3.1 Einführung Monitoring• 3.2 Allgemeiner Forschungsstand des Monitoring• 3.3 Forschungsstand Monitoring: MAC• 3.4 Forschungsstand Monitoring: MOP• 3.5 Forschungsstand Monitoring: Verteilte Systeme 11
    • 3.1 Einführung Monitoring• Fehlertolerante Konzepte in sicherheitskritischen Systemen können scheitern! ->Monitoring notwendig• Definition Monitor: – Ein Monitor beobachtet das Verhalten eines Systems und erkennt, wenn es im Einklang mit einer bestimmten Spezifikation ist. – Das überwachte System kann ein Programm, Hardware, Netzwerk, oder jede Kombination sein – Überwachte System: System under observation (SUO) – Falls SUO die Spezifikationen verletzt -> Warnung ausgegeben – Historisch: Monitoring auf funktionale Korrektheit ausgelegt • Aber auch auf non-funktional, wie Leistung 12
    • 3.1 Einführung Monitoring• Vergangenheit: Fokus auf off-line monitoring – Datensammlung und Analyse erfolgt offline (nicht dynamisch)• Fokus aktueller Forschung: Online-monitoring – Spezifikation wird mit ausführten Programm dynamisch geprüft (Praktisch: beim Testen, z.B. hohe Ressourcen)• Online-Monitoring: Implementierung – in-line: Monitor im Programmcode wie Kommentare • Anna CCS: Aus Kommentare mit Eigenschaften werden Funktionen generiert, arbeiten an dieser Stelle als Monitor • JAVA 5:Grundlegende Behauptungen in Code möglich – out-line: Monitor außerhalb des Programms als eigener Prozess 13 – Auch Kombination von out- und inline möglich
    • 3.2 Allgemeiner Forschungsstand des Monitoring• Forschungsherausforderungen an online monitoring: – Implementieren von effizienten Monitoren, welche mit Verhaltensspezifizierungen höheren Ebenen synthetisiert werden – Voraussetzung dafür: Monitor teilt Ressourcen mit beobachteten System – Fokus der Synthese: Sicherheitseigenschaften aus „temporal logic“ (zeitabhängige Logik) zu gewinnen: wie z.B. „Es kann niemals was schlimmes passieren“• z.B. EAGLE: Regeln-basiertes Framework, mit LTL – Effiziente Monitore aus linear temporal logic (LTL) generieren-> realtime Nasa roverForschung: Monitoring Java applications und erkennen von deadlocked threadsState-of-the-Art: MaC & MOPAusnahme für “C”: Requirement monitoring and recovery (RMOR) 14 -
    • 3.3 Forschungsstand Monitoring: MAC• Monitoring and Checking (MaC) Framework – Ziel: Weiche Echtzeitsysteme in Java – Unterscheidung: in Integration und Monitor Aufgaben • Out- oder in-line ->komplex Outline – Sicherheitsspezifizierungen in Meta Event Definition Language (MEDL) ->zeitliche Satzlogik von Ereignissen und Bedingungen – Interpretiert über einen Pfad von Beobachtungen• The Primitive Event Definition Language (PEDL): definiert Ereignisse, Mapping von Spezifikationen• PEDL-Compiler: Input= Java Implementierung und PEDl Spezifizierung• 2 Produkte: Filter(sensor):beobachtet Monitor-Objekte;E.-R.:Erkennt geschickte Ereignisse• MEDL-Compiler: erzeugt Verifier, überprüft ob Event R. MEDL 15 Spezifizierungen einhält
    • 3.4 Forschungsstand Monitoring: MOP • MOP (Monitoring-Oriented Programming) • Ein Software-Entwicklungs- und Analyse Framework – Verringerung der Kluft zwischen formaler Spezifikation und Implementierung durch bilden eines gemeinsamen Systems – Laufzeitüberwachung als fundamentales Prinzip – Monitore werden automatisch aus angegebenen Eigenschaften synthetisiert – Dynamisches Verhalten während Ausführung, bei Fehlverhalten werden festgelegte Aktionen vom Nutzer ausgeführt->Self-recovery!-JavaMOP: MOP Tool fürJavaBusMOP: MOP tool fürMonitoring consumer off-the-shelf Produkte, über 16den PCI buss
    • 3.5 Forschungsstand Monitoring: Verteilte Systeme• Großteil der Forschung des Monitoring auf einheitliche, monolithische Software• Bauer: zentraler Ansatz – Monitoring Ansatz für lokale Eigenschaften erfordert nur Verweis eines Programms auf lokalen Knoten – Jeder Knoten überprüft sicherheitstechnische Eigenschaften – Sendet Bericht an zentrale Diagnose-Engine – Versucht Ursprung des Problems zu diagnostizieren und in sicheren Zustand zu lenken• Bhargavan: Überwachung verteilter Netzwerkprotokolle, wie TCP – Black-Box-Monitore: keine Kenntnisse des internen Zustands – Zeigen Netzwerktraffic, mimen Protokollaktivitäten als Reaktion des überwachten Inputs, vergleichen Output im Netzwerk – NERL: Network Event Recognition Language, Spezifizierung der Netzwerkereignisse mit spezialisierten Compiler 17
    • 4.Monitor-Architekturen für verteilte Echtzeitsysteme• 4.1 Theorie: Monitoring verteilter Echtzeitsysteme Systeme• 4.2 Hardware- / Softwareunterscheidung• 4.3 Anforderungen an Monitor Architekturen• 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme 18
    • 4.1 Theorie: Monitoring verteilter Echtzeitsysteme Systeme Argumentation: Monitore für DRTs brauchen keine neue Theorieansatz, subsumieren von aktuellen theoretischen Erkenntnissen ist hinreichend These: „Monitore für ein verteiltes System sind andere Prozesse in einem verteilten System“ – Impliziert: gibt keine „allwissende“ Ansicht zu verteilten Systemen – Monitor (Benutzer oder Prozess) sammelt Informationen wie jeder anderer Prozess im verteilten System – Monitor hat mehr Privilegien: z.B. genauere physikalische Uhr, direkte Kommunikationskanäle zu jedem Knoten – >könnte aber jeder andere Prozess auch bekommen 19
    • 4.1 Theorie: Monitoring verteilter Echtzeitsysteme Systeme• Konsequenzen für Monitoring DRT´s: – Jede theoretische Begrenztheit für verteilte Systeme gilt auch für deren Monitore – Verteilte Systeme: gut entwickelt, fundamentale Grenzen für Synchronisation, Fehlertoleranz, Fehlererkennung und Überwachung• Jedoch Komplexität in Bezug zu Synchronisation und Fehlern: – Macht verteilte Programmierung komplex – 2 Formen der Synchronisation: • Einfache Einigung: nach Reihenfolge der Ereignisse: logical clock synchronization • bei echter Zeit(wall-clock time), synchr. mit physikalischen Uhren – Uhren können sich aber nur in einem kleinen Zeitfenster synchronisieren – Fehler: Monitor selbst auch fehleranfällig: erkennt Fehler in SUO, kann aber auch an welchen erleiden ->“babbling monitor“: Sendet kont. 20 Fehler an System
    • 4.2 Hardware- / Softwareunterscheidung• Monitor-Ansätze werden in Hard – und Softwarelösungen unterschieden, bisher wurden Softwareansätze diskutiert• Unterscheidung für fehlertolerante Echtzeitsysteme weniger nützlich, sowohl aus Echtzeit, als auch fehlertoleranten Aspekten heraus• Echtzeitgarantien sind abhängig von Verhalten von Soft- und Hardware• Einseitige Monitore nicht praktikabel ->Wahrscheinlichkeitsaussage ob Hardware oder Softwarefehler• Deutlich oder öfters Frist nicht eingehalten Logikfehler ist wahrscheinlicher als Hardwarefehler• Einzelfallbetrachung nicht ausreichend zur Analyse von Fehlern• ->Wahrscheinlichkeitsmodelle mit Variablen der 21 Umwelt und Ausfallrate der Hardware
    • 4.3 Anforderungen an Monitor Architekturen• Monitor-Architektur: Integration von einen oder mehreren Monitoren in das SUO (System Under Observation)• Die Architektur schließt die ganze zusätzliche Hardware & Verbindungen ein, die erforderlich sind, die Überwachung auszuführen.• Welche Anforderungen müssen Monitorarchitekturen erfüllen?:• 1.Funktionalität: Der Monitor ändert nichts an der Funktionalität des SUO bis das SUO seine Spezifikationen verletzt.• 2.Planbarkeit: Die Monitor-Architektur veranlasst das SUO nicht, seine harten Echtzeitgarantien zu verletzen, es sei denn, dass das SUO seine Spezifizierung verletzt.• 3.Zuverlässigkeit: Die Zuverlässigkeit der SUO, im Rahmen der Monitor Architektur, ist größer oder gleich der Zuverlässigkeit der SUO alleine.• 4.Zertifizierbarkeit: Die Monitor-Architektur erfordert nicht übermäßig Änderungen am Quellcode oder Objektcode der SUO. 22
    • 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme• Welche potentiellen Monitorarchitekturen kommen für verteilte Echtzeitsysteme in Frage?• 3 abstrakte Monitorarchitekturen welche die 4 Anforderungen erfüllen• Architekturen sind auf konzeptionelle Ebene: – Können in zukünftigen Studien untersucht werden• Abbildungen zeigen verteilte SUO mit Monitor- Architektur – Monitorarchitektur mit Reihe verteilter Prozesse x1, x2… xn in Verbindung mit Leiterbahn 23
    • 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme Bus-Monitor Architektur – Monitor überwacht Verkehr am Datenbus des SUO – Empfängt Nachrichten wie jeder andere Prozess – Stille Teilnehmer: zusätzliche Fehlerprüfung oder prüfen der Einhaltung des Kommunikationsprotokoll – Nur bei katastrophalen Fehler sendet es Nachrichten zu den Prozessen durch den Bus• Einfach: Realsierung durch Peripherie-Hardware• Siehe Bhargavan: TCP-Pakete abfangen• Begrenzt: Beurteilt nur Aktivitäten im Bus, SUO könnte es selber regeln 24• commercial-off-the-shelf Produkte
    • 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme Single-Process Monitor Architektur • Bus zu teilen kann zu Fehlern führen, falls Monitor defekt ist und Bus mit Nachrichten flutet • Jeder Prozess und einzelner Monitor ist an Datenbus angebunden • Einzelner Prozess sendet Daten zu einzelnen Monitor zum Vergleich -> Monitor signalisiert Prozess Fehler• Separater Monitor Bus zur Überwachung der Nachrichten • Monitor gefährdet nicht Kommunikation und SUO, Designfehler werden reduziert 25
    • 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme Distributed Process - Architektur – Verteilte Monitor: M0 … Mn überwacht Prozess x0... xn – Monitor Mi auf gleicher Hardware wie Prozess xi (günstigere Hardwarekosten) oder FCR (sicherer da physikalisch getrennt) – Monitor-Verbindung kann Fehlertolerant sein, auch wenn SUO Verbindung es nicht ist -> Fehlertoleranz wird garantiert – Verteilte Online-Monitore müssen kommunizieren ->Einigungen zu Diagnosen• Vergleich zu Single Process Architektur: Zuverlässige Kontrolle, da Monitore verteilt• Beschützer: Monitor Mi als Vormund eines Prozess xi• „Plapper“-Prozess kann nicht wie Single-Process Monitor Architektur alles blockieren• Komplexität kann Zuverlässigkeit des Monitor 26 reduzieren, Aufwand ist so hoch wie SUO selbst
    • 5. Wichtige zu überwachende Eigenschaften im Monitoring• 5.1 Rückblick Problemstellung MFA• 5.2 Monitoring Konsens Verletzungen - „Fault-Model“ - Verletzungen• 5.3 Monitoring Konsens Verletzungen – „Point-to-Point Error-Checking“• 5.4Monitoring Konsens Verletzungen – „Timing violations “ 27
    • 5.1 Rückblick Problemstellung MFAWas soll in Monitoren überwacht werden?• Sicherheitskritische Systeme können durch Design-Fehler (systematische Fehler) scheitern, z.B. durch falsche Architekturkonzepte ->Hier muss Monitoring ansetzenRückblick MFA: Konzeption Fehlertoleranter Systeme• Sicherheitskritische Systeme wurden entworfen um MFA (max Fehler-Annahme) stand zu halten, stat. Einbezug von Umweltkriterien• Faktoren sind zur Designzeit der Systeme unterspezifiziert -> System wird nach geschätzter Betriebszeit weitergenutzt oder für andere Aufgaben verwendet• MFA: Besteht Annahme, dass keine systematischen Softwarefehler existieren -> Designer unterschätzen die MFA, die zur Erreichung der gewünschten Zuverlässigkeit benötigt wird• Geschätzte Zuverlässigkeit < tatsächliche Zuverlässigkeit 28• Lösung durch Monitore?
    • 5.2 Monitoring Konsens Verletzungen – „Fault-Model“ - Verletzungen• Monitor Konsens (Übereinstimmung der Kommunikation): • Monitor kann (fehlenden) Konsens zwischen verteilten Komponenten feststellen • Ziel des Konsens: Jeder Empfänger einer Broadcast-Nachricht erhält den selben Wert • Überwachung des Konsens während der Laufzeit: – Empfangene Werte müssen überprüft werden – Exakte Übereinstimmung: Jeder Empfänger bekommt gleichen Wert – Geschätzte Übereinstimmung: Empfänger bekommt ungefähren Wert, welcher innerhalb eines kleinen Delta liegt • Im Fokus: Asymmetr./Byzantischer Fehler (wurden ausgeschlossen!) – Empfänger tauschen Nachrichten aus, um Werte zu vergleichen und Konsens zu garantieren ->Problem des Konsens – Monitore können je nach Architektur zur Lösung beitreten: – Bus-Architektur: - Broadcast-Nachrichten: Monitor nur weiterer Empfänger – Single-Process: + Jeder Knoten zu Monitor verbunden 29 – Distrubuted-Process: ++ Jeder Knoten einen Monitor
    • 5.3 Monitoring Konsens Verletzungen – „Point-to-Point Error-Checking“• Punkt-zu-Punkt Fehlerprüfung weißt dem Empfänger nach, falls eine Nachricht während der Übertragung beschädigt wurde• CRC s (cylic redundant checks) ist das Standard-verfahren um Punkt-zu-Punkt Kommunikationsfehler zu finden – Können Burstfehler oder zufällige Bitfehler sein – Einfach in Hardware zu implementieren – Einsatz in embedded-systems• CRC´s arbeiten jedoch nicht ulta-zuverlässig – Hauptproblem: Netzwerkkapselung fälscht CRC-Sequenzen (Schrödingers CRC)->Problem des byzantinischen Fehlers – Falsche Nachrichten werden als fehlerfrei „erkannt“• Lösung: Architektur fehlertolerant (re)designen, eigener Bus – Optimierung: Monitore mit CRC-Check implementieren – Vorteil: CRC braucht weniger Bandbreite als die Nachricht – Spezielle Monitoring-Nachrichten von Knoten zu Monitor 30
    • 5.4Monitoring Konsens Verletzungen –„Timing violations “• Harte Echtzeitsysteme liefern Echtzeitzeitgarantien, wenn Timing- Annahmen vom System gehalten werden, wenn Bedingungen (Constraints) wie: – Nachrichtenverzögerung, Resynchronisation, … eingehalten werden.• Bedingungen können nicht direkt überwacht werden – Ein Monitor hat nicht mehr Möglichkeiten als das SUO – Constraints verbinden im Wesentlichen die Werte von lokalen Hardware-Uhren zu einander und zur "echten" ("wall-clock") physischen Zeit. – Monitore können nur Abwesenheit von Fehlern aufzeigen – Fehlerursache (Hard-Software) kann nicht bestimmt werden – Lösung: Monitore mit Wahrscheinlichkeitsmodellen • Erfordern aber korrekte Umweltvariablen 31
    • 6.Zusammenfassung• Was sind Monitore? – Input: Lokale Zustands-Abbildungen der einzelnen Knoten/Prozesse – Daten sind fehlerbehafte Wahrscheinlichkeiten und Ansammlung von Zustandszeiten – Zustand ist von relativer Häufigkeit – Output ist eine Konsens Verletzung• Vorteile von Monitoren: – Ultra - Sicherheitskritische Systeme profitieren von neuen Ansätzen, in Verbindung zu vorgestellten Architekturen – Überwachung der vorgestellten Konsensklassen deckt einen Großteil der auftretenden Fehler ab – Erfolgreiche Monitore erfordern auch ein entsprechende Hardwarearchitektur• Zukunft: Zwei potentielle Architekturen: • Verteilt: – Monitore sind verteilten Knoten und tauschen Konsens-Daten aus • Zentral: – Knoten senden Konsens-Daten zu einem zentralen Monitor • Folge: Monitorkonzepte und Architekturen nach Verwendungszweck • Kombinieren verschiedener Architekturen 32