12 Fehlertoleranz. Begriffe. Failure das System verhält sich nicht wie spezifiziert.
|
|
- Paula Weber
- vor 6 Jahren
- Abrufe
Transkript
1 12 Fehlertoleranz ein verteiltes System beinhaltet viele Abstraktionsebenen, die stark voneinander abhängen. z.b. hängt der Klient von seinem Server ab, der wiederum von seinen Diensten, etc. die Kette der Abhängigkeiten setzt sich durch die Softwareebenen bis zur Hardware fort. Fehlertoleranz bedeutet, dass das Gesamtsystem einen Fehler einer Komponente in den Abhängigkeitsrelationen maskiert. das Fehlverhalten einer Komponente wird vom Gesamtsystem ausgeglichen. Begriffe Failure das System verhält sich nicht wie spezifiziert. Error Teil eines Systemzustands, der verantwortlich für eine zukünftige Failure ist, falls keine entsprechenden Maßnahmen getroffen werden. Fault die Ursache eines Errors.
2 2 12 Fehlertoleranz da ein Error Teil des Systemzustandes ist, lässt sich dieser beobachten und evaluieren. eine Failure (d.h. Fehlverhalten) ist nicht leicht observierbar. sie muss mit speziellen Mechanismen aus einem Error abgeleitet werden. wenn nicht jeder Systemzustand erfasst wird, kann Fehlverhalten entstehen, ohne dass es bemerkt wird. ein (verteiltes) System ist fehlertolerant (engl.: fault tolerant), wenn es in der Lage ist, sich trotz des Auftretens von Faults spezifikationskonsistent zu verhalten. Redundanz wird als Schlüsselverfahren auf drei Ebenen eingesetzt. bei Hardwareredundanz werden Hardwarekomponenten zusätzlich im System hinzugefügt. bei Softwareredundanz werden Softwarekomponenten oder Codesegmente mehrfach bereitgehalten und ausgeführt. bei Zeitredundanz wird zusätzliche Ausführungszeit für die vorgenannten Techniken spendiert.
3 3 Phasen eines fehlertoleranten Systems Fehlererkennung (engl.: error detection) ein Fehler wird im Zustand bemerkt (error) und daraus auf einen Fehler (fault) in einem Teil des Systems geschlossen. Man nimmt an, dass dann ein Fehlverhalten (failure) der betroffenen Komponente des Systems auftritt. Schadensermittlung (engl.: damage confinement) welcher Schaden ist bis zum Zeitpunkt der Erkennung aufgetreten. die Auswirkungen sollten auf einen bekannten und beschränkten Bereich eingegrenzt werden können. Fehlerrecovery (engl.: error recovery) der aufgetretene fehlerhafte Zustand wird behoben. das System wird in einen korrekten Zustand gebracht. Fehlerbehandlung und Weiterführen des Systems (engl.: fault treatment and continued system service) das fehlertolerante System soll spezifikationskonform weiter arbeiten die fehlerhafte Komponente wird umgangen oder in einer anderen Konfiguration verwendet.
4 4 12 Fehlertoleranz in sicherheitskritischen Systemen wird Fehlertoleranz oft durch redundante Auslegung der Hardware realisiert. z.b. drei identische Hardwarekomponenten (engl.: triple modular redundancy, TMR), die mit den gleichen Eingaben im gleichen Takt arbeiten. aus den drei Ergebnissen entscheidet die Majorität. dadurch ist das System gegenüber dem Ausfall und der Fehlfunktion einer Komponente tolerant. bei nur zwei Replikaten könnte nur der Ausfall einer Komponente maskiert werden.
5 5 Ebenen und Bausteine fehlertoleranter Software Bausteine Fail-Stop Prozessoren beenden ihre Tätigkeit bei einem entdeckten Fehler und arbeiten nicht fehlerhaft im System weiter. in stabilem Speicher sind Daten auch nach dem Auftreten eines Fehlers fehlerfrei verfügbar. durch zuverlässige Kommunikation werden Nachrichten sicher und in der richtigen Reihenfolge zugestellt. auf den Basiselementen kann zuverlässige und atomare Broadcastkommunikation aufgebaut werden. unter Verwendung der Bausteine lassen sich unterschiedlich tolerante Dienste entwickeln. Fehlertoleranz- Dienste Bausteine fehlertolerante Software Prozeß-Zuverlässigkeit (Process-Resilience) Daten-Zuverlässigkeit (Data-Resilience) atomare Aktionen konsistente Zustands-Recovery zuverlässiger und atomarer Broadcast Fail-Stop Prozessoren, stabiler Speicher, zuverlässige Kommunikation verteiltes System fortgesetzter Dienst bei Designfehlern fortgesetzter Dienst bei Knotenfehlern Konsistenz bei Knotenfehlern Bild 12.1: Ebenen in einem fehlertoleranten verteilten System
6 6 12 Fehlertoleranz 12.1 Fehlersemantik Fehlersemantik beschreibt das Verhalten von Systemkomponenten und des gesamten Systems im Fehlerfall. Je nach Art des Fehlers wird das Fehlverhalten in verschiedene Klassen eingeteilt [Cri91] Dienstverweigerung (engl.: omission failure bzw. denial of service) eine Komponente reagiert nicht mit einer Antwort auf einen Auftrag. z.b. durch verlorengehende Nachrichten im Kommunikationsdienst. fehlerhafte Antwort eine Komponente antwortet falsch auf einen Auftrag (engl.: response failure). falsche Werte werden übermittelt (engl.: value failure) intern finden falsche Zustandsübergänge statt (engl.: state transition failure) und es entstehen lokal falsche Werte. Zeitfehler (engl.: timing failure) eine Komponente antwortet richtig, jedoch zum falschen Zeitpunkt. meist kommen die Antworten zu spät z.b. durch einen überlasteten Server oder schlechte Netzverbindung. Antworten können auch zu früh ankommen. z.b. in Echtzeitsystemen oder Multimediasystemen.
7 12.1 Fehlersemantik 7 Serverabsturz (engl.: crash failure) ein Server verweigert kontinuierlich seinen Dienst. er wird von Klienten als abgestürzt vermutet. weitere Unterscheidung je nach Zustand der Serverdaten nach Wiederanlaufen: Amnesie-Crash: der Server startet im Initialzustand. er verliert jegliche Datenzustände zum Zeitpunkt des Absturzes. Pause-Crash: der Server startet in dem Zustand, den er vor dem Absturz hatte. Halte-Crash: die fehlerhafte Komponente steht nach dem Fehler und wird nicht erneut gestartet. Byzantinische Fehler eine Komponente verhält sich beliebig. es können beliebige Kombinationen der anderen Klassen vorkommen. oft sind Hardwarefehler dieursache von byzantinischen Fehlern. z.b. ein defekter Timerbaustein zerstört die Ordnung von Nachrichten.
8 8 12 Fehlertoleranz die Fehlersemantik beschreibt das Verhalten des Systems im Fehlerfall. d.h. ein fehlertolerantes System muss dies maskieren. z.b. muss ein Service mit Omission-Semantik zur Fehlertoleranz so erweitert werden, dass verlorengehende Aufträge automatisch vom Klienten wiederholt werden. je mehr Fehlersemantiken tolerant begegnet werden soll, um so aufwendiger wird die Programmierung. die starke Schichtung eines Systems aus Mechanismen und Diensten bedingt eine hohe Abhängigkeit der Komponenten. Fehler werden von unteren Schichten in die höheren propagiert. dabei können sich Fehlerklassen ändern und sehr komplexe Phänomene auftreten.
9 12.1 Fehlersemantik 9 Maskierung von Fehlern Hierarchische Maskierung Fehler von Diensten oder Komponenten niedrigerer Ebene werden von den sie nutzenden Komponenten höherer Ebene maskiert. ist eine Maskierung auf einer unteren Ebene nicht möglich, wird eine Ausnahme (engl.: exception) auf höherer Ebene ausgelöst, um dann dort maskiert zu werden. einfaches Beispiel: Abfrage auf Division durch Null, wenn die Divisionshardware dies nicht selbst melden kann. IF Nenner <> 0 THEN Teile... ELSE Fehlerbehandlung... Wenn auf allen Ebenen die Maskierung unmöglich ist, muss letztlich der Benutzer über die Ausnahme informiert werden. Maskierung durch Gruppenbildung der Fehler einer einzelnen Komponente wird durch die Replikation der Funktionalität in einer Gruppe verborgen. eine Gruppe heisst k-fehlertolerant, wenn sie den gleichzeitigen Ausfall von k Mitgliedern maskieren kann. es genügen k+1 Gruppenmitglieder, um das Fehlverhalten von k Komponenten zu maskieren. für byzantinische Fehler werden 3k+1 Mitglieder benötigt, da eine Mehrheitsentscheidung notwendig ist.
10 10 12 Fehlertoleranz 12.2 Passive Redundanz Passive Redundanz kann durch den Primary-Backup-Ansatz erreicht werden. es existieren k Replikate von Prozessen oder Daten, wobei ein Replikat als Primärserver fungiert. die restlichen Replikate arbeiten als Backup. Anfragen werden immer an den Primärserver gestellt. ist der Primärserver fehlerhaft oder antwortet nicht, wird er durch einen Backupserver ersetzt. Aktualisierung der Backupserver: Hot-Standby die Backupserver laufen synchron mit dem Primärserver mit. alle Anfragen gehen an alle Server. die Antwort wird nur vom Primärserver erbracht. beim Ausfall des Primärservers ist sofort ein Backupserver verfügbar. Warm-Standby Aufträge werden beim Primärserver gespeichert und periodisch den Backupservern übermittelt. die Backupserver werden dadurch nachgezogen. nach einem Ausfall muss der letzte Backupblock noch bearbeitet werden. ein Backupserver steht nach kurzer Zeit zur Verfügung.
11 12.2 Passive Redundanz 11 Cold-Standby alle Aufträge und Datenveränderungen werden beim Primärserver stabil gespeichert. fällt der Primärserver aus, muss anhand dieser Daten ein Backupserver vollständig nachgezogen werden. die Verzögerung für das Fortsetzen des Dienstes ist unter Umständen recht lang. damit Lebendigkeit und Verfügbarkeit des Primärservers überwacht werden kann, sendet dieser meist periodisch ALIVE- Nachrichten an seine Backupserver. werden eine bestimmte Zeit keine ALIVE-Nachrichten empfangen, vermuten die Backupserver, dass der Primärserver nicht mehr verfügbar ist. die Backupserver wählen unter sich einen neuen Primärserver. Passive Redundanz kann einen Knotenfehler, d.h. omission, des Primärservers maskieren. Passive Redundanz wird auch als lose Synchronisation bezeichnet.
12 12 12 Fehlertoleranz 12.3 Aktive Redundanz alle beteiligten Komponenten bzw. Server sind als Zustandsmaschinen mit identischen Übergangsfunktionen implementiert. Anfragen und Kommandos von außen verändern die Zustände aller Server synchron. wenn die Zustandsmaschinen im gleichen initialen Zustand beginnen und Kommandos in der gleichen Reihenfolge bearbeiten, befinden sich alle Maschinen immer im gleichen Zustand und erzeugen identische Ausgaben. aktive Redundanz bezeichnet man auch als enge Synchronisation. fällt eine Komponente aus, kann dies zu jedem Zeitpunkt maskiert werden. Die Maskierung eines Fehlers erfordert Übereinkunft (engl.: agreement) und Ordnung (engl.: order). Übereinkunft: jede nicht-fehlerhafte Zustandsmaschine empfängt alle Kommandos und weiss welche anderen nicht-fehlerhaft sind. Ordnung: die empfangenen Kommandos werden bei allen Servern in der gleichen Reihenfolge ausgeführt. Übereinkunft kann durch ein byzantinisches Übereinkunftsprotokoll für byzantinische Fehler oder durch einen zuverlässigen Broadcast bei Fail-Stop-Verhalten realisiert werden. Ordnung kann man durch eindeutige Identifikatoren aller Nachrichten und eine totale Ordnung über diese Identifikatoren erreichen.
13 12.3 Aktive Redundanz 13 theoretisch lässt sich in verteilten Systemen bei asynchronen Prozessen und unbeschränkter Nachrichtenlaufzeit Übereinkunft nicht erzielen [FLP85]. daher ist immer eine Restwahrscheinlichkeit gegeben, dass das fehlertolerante System Fehlverhalten zeigt. Byzantinisches Generalsproblem auf den Hügeln um Byzanz stehen die Truppen einiger römischer Generäle. um den Angriff zu koordinieren, melden sich die Generäle gegenseitig ihre Truppenstärken. keiner der Generäle kann sicher sein, dass nicht ein anderer General bestochen wurde und falsche Angaben macht, bzw. dass Nachrichten während der Übermittlung verfälscht werden. Beispiel X Y 4 Z 3 4 Bild 12.2 Byzantinisches Generalsproblem 4
14 14 12 Fehlertoleranz Übereinkunftsprotokoll von Lamport, Shostak und Pease 1982: die Generäle teilen sich ihre Truppenstärken mit und erhalten folgende Information: 1: (1,2,X,4)2: (1,2,Y,4)3: (1,2,3,4)4: (1,2,Z,4) die Generäle tauschen die gesammelten Informationen untereinander aus und haben danach folgende Entscheidungsgrundlage: 1: (1,2,Y,4)2: (1,2,X,4)3: (1,2,X,4)4: (1,2,X,4) (a,b,c,d) (e,f,g,h) (1,2,Y,4) (1,2,Y,4) (1,2,Z,4) (1,2,Z,4) (1,2,Z,4) (i,j,k,l) jeder General kann selbst eine Majoritätsentscheidung durchführen. z.b. ist für General 1 klar, dass die Werte an den Positionen 1, 2 und 4 korrekt sind und der dritte General ein Fehlverhalten aufweist. mit dem Algorithmus können 3k+1 Komponenten k fehlerhaft arbeitende Komponenten maskieren. für die Mehrheitsentscheidung sind 2k+1 funktionstüchtige Komponenten notwendig (mehr als zwei Drittel).
15 12.3 Aktive Redundanz 15 Beispiel: 2k+1 Komponenten reichen nicht aus (hier: k=1). in beiden Szenarien weiss A nicht, welcher der beiden anderen Knoten fehlerhaft ist, da er jeweils die gleichen Nachrichteninhalte empfängt. B 1 1 B 1 0 fehlerhaft A 0 C fehlerhaft A 0 C Bild 12.3 Byzantinische Übereinkunft ist mit 2k+1 Komponenten unmöglich
16 16 12 Fehlertoleranz 12.4 Zuverlässigkeit bei Softwaredesignfehlern Problem: verwendet man für die Redundanz identische Software, wird ein Programmierfehler in allen Replikaten zum Tragen kommen. N-Versionen-Programmierung ein Problem wird von N verschiedenen Entwicklungsteams oder in N Varianten unabhängig voneinander bearbeitet. es entstehen N verschiedene Designs, welche die gleiche Funktionalität und identische Schnittstellen bieten. mit sehr hoher Wahrscheinlichkeit haben die einzelnen Versionen unterschiedliche Fehler, so dass sie gegenseitig die Fehler einzelner maskieren können. alle Programme laufen gleichzeitig aktiv redundant mit den gleichen Eingaben. die mehrfache Ausgabe wird durch einen Mehrheitsentscheid in eine einzige Ausgabe überführt. es muss beachtet werden, dass unter Umständen nicht auf exakte Gleichheit geprüft werden kann (engl.: consistent comparison problem). eine Berechnung mit Gleitkommazahlen kann mit unterschiedlicher Rechenreihenfolge unterschiedliche Rundungsfehler erzeugen. weiteres Problem: die Laufzeit wird immer von der langsamsten Komponente bestimmt.
17 12.4 Zuverlässigkeit bei Softwaredesignfehlern 17 Recoveryblock in einer Komponente werden kritische Kodepassagen in mehreren Versionen implementiert. die Komponente führt zuerst die Primärversion aus und prüft das Ergebnis durch einen Akzeptanztest gegen die Spezifikation. ist ein Fehler aufgetreten, wird der ursprüngliche Zustand wiederhergestellt und die nächste alternative Version benutzt. die Alternativen lassen sich schachteln. Beispiel: ensure <acceptance test> by <primary module> else by <alternate module 1>... else by <alternate module n> else error ein Akzeptanztest ist kein vollständiger, erschöpfender Test aller Systemanforderungen, sondern eher eine Stichprobe. er ist dazu so flexibel zu halten, dass mehrere leicht unterschiedliche Ausgaben der zu testenden Module zulässig sein können. man kann dynamisch durch verschiedene Akzeptanztests auch unterschiedliches Verhalten des Systems ermöglichen. wenn der erste Akzeptanztest nicht erfolgreich ist, führt man einen abgeschwächten Test mit geringeren Anforderungen durch. wird dies wiederholt vorgenommen, kann ein adaptives System mit automatisch angepasster reduzierter Funktionalität realisiert werden (engl.: graceful degradation).
12 Fehlertoleranz. Begriffe
12 Fehlertoleranz ein verteiltes System beinhaltet viele Abstraktionsebenen, die stark voneinander abhängen. - z.b. hängt der Klient von seinem Server ab, der wiederum von seinen Diensten, etc. - die Kette
MehrVerteilte Systeme F. Fehlertoleranz
Verteilte Systeme F. Fehlertoleranz Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.1 Fehlertoleranz Abhängigkeiten in einem verteilten System: Client! Server! Dienste! Software!
Mehr7 Fehlertoleranz. vs7 1
7 Fehlertoleranz vs7 1 Zuverlässigkeit (reliability) Sicherheit vor Fehlern (safety) Sicherheit vor Angriffen (security) -> Systemsicherheit -> Netzsicherheit vs7 2 7.1 Terminologie (ist nicht einheitlich)
MehrFehlertoleranz in eingebetteten Systemen
Fehlertoleranz in eingebetteten Systemen Ausgewählte Kapitel eingebetteter Systeme (AKES) 19.07.2006 1 / 36 Was ist ein Fehler? Fehlerklassen Überblick Einführung Was ist ein Fehler? Fehlerklassen 2 /
MehrVerteilte Systeme. 7. Fehlertoleranz
Verteilte Systeme 7. Fehlertoleranz Sommersemester 2011 Institut für Betriebssysteme und Rechnerverbund TU Braunschweig Dr. Christian Werner Bundesamt für Strahlenschutz 7-2 Überblick Motivation für Fehlertoleranz
MehrVorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13.
Verteilte Systeme 13. Fehlertoleranz Motivation Kunde () Verteiltes System = Redundanz Rechnern Kommunikationsnetzen Grundidee Einzelne Komponente k fällt mit einer Wahrscheinlichkeit p aus Ausfallwahrscheinlichkeit
MehrFehlertolerante Systeme
Wissenschaftliche Vertiefung Studiengang Technische Informatik Fehlertolerante Systeme Philipp Dürnay 22.01.2016 Agenda Fehlertoleranz Fehlerdiagnose Fehlerbehandlung Beispielsystem Ausblick Philipp Dürnay
MehrFehlertolerante und Selbstheilende Systeme. Redundanztechniken
Fehlertolerante und Selbstheilende Systeme Redundanztechniken Azad Kamo Seminar Fehlertolerante und Selbstheilende Systeme: Redundanztechniken Azad Kamo - 1 Gliederung Motivation Fehler Ziele der Fehlertoleranz
MehrGrundlagen: Überblick
Grundlagen: Überblick Verteilte Systeme Definition Grundbegriffe Kommunikation Klassifikation von Fehlern Begriffe Fehlerarten Analyse von Algorithmen Korrektheit Komplexität Verteilte Algorithmen (VA),
MehrVerteilte Systeme - Übung
Verteilte Systeme - Übung Schriftliche Übungen Dienen der Klausurvorbereitung Zwei Teile: Serie A: Okt - Nov Serie B: Nov - Jan 3% der Endnote je Serie Ansprechpartner: Harald Vogt Heute:
MehrÜberblick. Replikation Motivation Grundlagen Aktive Replikation Passive Replikation. c td VS (SS16) Replikation 6 1
Überblick Replikation Motivation Grundlagen Aktive Replikation Passive Replikation c td VS (SS16) Replikation 6 1 Motivation Zielsetzungen Tolerierung permanenter Server-Ausfälle Hohe Verfügbarkeit von
MehrVorlesung Systemsoftware II Wintersemester 2002/03
Verteilte Systeme 14. Fehlertoleranz Warum? Zunehmende Durchdringung Menschenleben hängen von kritischen Computersystemen ab Unternehmen hängen von der Verfügbarkeit der IT ab Hohe Verfügbarkeit (HA) Kompensation
MehrFEHLERTOLERANZ EINE SEHR GROBE ÜBERSICHT BETRIEBSSYSTEME UND SICHERHEIT, WS 2016/17 HERMANN HÄRTIG
Faculty of Computer Science Institute of Systems Architecture, Operating Systems Group FEHLERTOLERANZ EINE SEHR GROBE ÜBERSICHT BETRIEBSSYSTEME UND SICHERHEIT, WS 2016/17 HERMANN HÄRTIG BEGRIFFE Sicherheit/Security/Safety
MehrPraktikable Einigungsalgorithmen
Praktikable Einigungsalgorithmen Algorithmen für synchrone Systeme Atomarer Broadcast: siehe Aufgabe 4.4 Burns/Neiger Lamport/Shostak/Pease: Oral Messages; Signed Messages Algorithmen für asynchrone Systeme
MehrZuverlässige Systeme Fehlertoleranz
Zuverlässige Systeme Fehlertoleranz frank@upb.de Inhalt Übersicht und Namenskonventionen Was ist Fehlertoleranz Eine Anleitung in 4 Phase Redundanz und Vielfältigkeit Hardwareseitige Fehlertoleranz Softwareseitige
MehrFehlertoleranz. Betriebssysteme. Hermann Härtig TU Dresden
Fehlertoleranz Betriebssysteme Hermann Härtig TU Dresden Wegweiser Prinzipien der Fehlertoleranz RAID als ein Beispiel Betriebssysteme WS 2018, Fehlertoleranz!2 Begriffe Grundprinzip Konstruktion zuverlässigerer
MehrSicherheit (Safety): Fehlerfall hat keinen katastrophalen Effekt - Menschenleben nicht gefährdet, - Datenbestand nicht zerstört.
8. Fehlertoleranz 8.1 Terminologie Umfassenderer Begriff: Verlässlichkeit. Verfügbarkeit (Availability): Wahrscheinlichkeit für das korrekte Arbeiten des Systems zu gegebenem Zeitpunkt. Zuverlässigkeit
MehrVerteilte Systeme. Fehlertoleranz. Prof. Dr. Oliver Haase
Verteilte Systeme Fehlertoleranz Prof. Dr. Oliver Haase 1 Überblick Einführung Belastbarkeit von Prozessen Zuverlässige Client-Server-Kommunikation Zuverlässige Gruppenkommunikation 2 Anforderungen an
MehrEs gibt 2 gebräuchliche Arten, wie erkannte Fehler dem Aufrufer bekannt gegeben werden:
Introduction to Detection Patterns Der erste Schritt für die Fehlertoleranz ist die Erkennung von Fehlern; es ist die Voraussetzung für Fehler Entschärfung (mitigation) und Erhohlung (recovery). Es ist
MehrGrundlagen: Überblick
Grundlagen: Überblick Verteilte Systeme Definition und Grundbegriffe Modellierung von Systemeigenschaften Punkt-zu-Punkt-Verbindungen Multicast-Kommunikation Synchrone und asynchrone Systeme Fehler und
MehrMotivation für Fehlertoleranz in VS Fehlermodelle Erreichen von Fehlertoleranz. Verteilte Systeme. 7. Fehlertoleranz
7-2 Überblick Verteilte Systeme 7. Fehlertoleranz Sommersemester 2011 Motivation für Fehlertoleranz in VS Fehlermodelle Erreichen von Fehlertoleranz Ausfallsicherheit von Prozessen Zuverlässiger Remote
MehrByzantinische Fehlertoleranz durch Gruppenkommunikation am Beispiel des Rampart-Toolkit Frank Mattauch
1 Hauptseminar: Moderne Konzepte für weitverteilte Systeme: Peer-to-Peer-Netzwerke und fehlertolerante Algorithmen (DOOS) Byzantinische Fehlertoleranz durch Gruppenkommunikation am Beispiel des Rampart-Toolkit
MehrGrundlagen verteilter Systeme
Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Aufgabe 1: Wintersemester 07/08 Übungsblatt 6 15.01.08 Grundlagen verteilter Systeme Lösungsvorschlag
MehrVorlesung "Systemsoftware II" Wintersemester 2002/03
(c) Peter Sturm, Universität Trier 1 Verteilte Systeme 16. Transaktionen Motivation Sicherung konsistenter Systemzustände Beispiele Amnesieproblematik bei zustandsbehafteten Servern Sicherung des Primaries
MehrVorlesung "Verteilte Systeme" Wintersemester 2000/2001. Verteilte Systeme. 14. Transaktionen
Verteilte Systeme 14. Transaktionen Motivation Sicherung konsistenter Systemzustände Beispiele Amnesieproblematik bei zustandsbehafteten Servern Sicherung des Primaries (Primary-Backup- Approach) Aktive
MehrMotivation. Gruppenkommunikation. Verteilte Anwendung. Gruppenkommunikation. HW-Multicast div. GC-Impl totale Ord. Kommunikationsnetz
s s Gruppenkommunikation Motivation Kommunikation bei der Programmentwicklung bewährter, verstandener Mechanismus Bei Gruppenkommunikation verschieden teuere semantische Varianten möglich (dadurch ggf.
MehrFehlertoleranz & Robustheit
January 17, 2017 Warum Recap fault error failure transient - permanent - intermittent Kritische Anwendungen - Extreme Umgebung - Komplexität Trends: Miniaturisierung kleiner Streuung in Fertigung einfach
MehrEntwurfsmuster und Softwarearchitekturen für sicherheitskritische Systeme
1 Entwurfsmuster und Softwarearchitekturen für sicherheitskritische Systeme Für das Seminar Analyse, Entwurf und Implementierung zuverlässiger Software Von: Andreas Seibel Betreut durch: Dr. Holger Giese
MehrFormale Grundlagen der Fehlertoleranz in verteilten Systemen
1/27 Formale Grundlagen der Fehlertoleranz in verteilten Systemen Felix Gärtner TU Darmstadt felix@informatik.tu-darmstadt.de 2/27 Bezug zur formalen Softwareentwicklung formale SE Definitionsphase Aufsplittung
MehrVerlässliche Systeme
Verlässliche Systeme Konzepte der Fehlertoleranz Rachid El Abdouni Khayari Universität der Bundeswehr München, Neubiberg, Fakultät für Informatik, Institut für Technische Informatik Herbsttrimester 2004
MehrAlgorithmus von Berkeley (1989)
Annahme: kein UTC Empfänger verfügbar Algorithmus (zentral, intern): Algorithmus von Berkeley (1989) ein Rechneragiert als aktiver Time Server. Der Server fragt periodisch die Zeiten/Unterschiede aller
MehrVor- und Nachteile der Fehlermaskierung
Vor- und Nachteile der Fehlermaskierung Fehlermaskierung reicht als einziges Fehlertoleranz-Verfahren aus. Maskierer lassen sich vergleichsweise einfach implementieren. Wiederholungsbetrieb entfällt, dadurch
MehrVerteilte Systeme. Replikation & Konsistenz I. Prof. Dr. Oliver Haase
Verteilte Systeme Replikation & Konsistenz I Prof. Dr. Oliver Haase 1 Überblick Replikation & Konsistenz I Ziele von Replikation Replikationsmodelle datenzentriert Client-zentriert Replikation & Konsistenz
MehrSeminar: Fehlertolerante und Selbstheilende Systeme
Seminar: Fehlertolerante und Selbstheilende Systeme Juniorprofessor Dr. Holger Giese, Stefan Henkler, Matthias Tichy FG Softwaretechnik Raum E 3.165 Tele. 60-3321 [hg,mtt,shenkler]@upb.de Fehlertoleranz
MehrDie Byzantinischen Generäle
Die Byzantinischen Generäle Von Doris Reim und Bartek Ochab aus dem Artikel: The Byzantine Generals Problem by Leslie Lamport, Robert Shostak, Marshall Pease Agenda I. Einleitung II. Lösbarkeit? III. OM-Algorithmus
MehrProseminar Technische Informatik WS08/09 bei Georg Wittenburg, M.Sc. Zuverlässigkeit und Fehlertoleranz in der Technik
Proseminar Technische Informatik WS08/09 bei Georg Wittenburg, M.Sc. Zuverlässigkeit und Fehlertoleranz in der Technik Ein Vortrag von Sebastian Oliver Kalwa Berlin, 30.01.2009 1 Was ist Fehlertoleranz?
MehrThe Byzantine Generals' Problem
Proseminar Technische Informatik The Byzantine Generals' Problem Esra Ünal Gliederung 1.Beispiel: meldeanlage 2.Formalisierung des Problems 3.Definition 4.Ursprung der Namensgebung 5.Voraussetzungen für
MehrFakultät für Informatik der Technischen Universität München. Fehlertoleranz. Redundanz
Fehlertoleranz Redundanz 476 Grundlage der Fehlertoleranzmechanismen: Redundanz Die beiden grundsätzlichen Schritte eines Fehlertoleranzverfahrens, die Diagnose und Behandlung von Fehlern, benötigen zusätzliche
MehrÜberblick. Multicast Motivation Grundlagen Zustellungsgarantien Ordnungsgarantien Paxos. c td VS (SS17) Multicast 7 1
Überblick Multicast Motivation Grundlagen Zustellungsgarantien Ordnungsgarantien Paxos c td VS (SS17) Multicast 7 1 Motivation Fehlertoleranz durch Replikation Redundante Applikationsinstanzen auf unterschiedlichen
MehrGrundlagen verteilter Systeme
Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 7 17.12.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: a)
Mehr16. Ausnahmebehandlung Programmieren / Algorithmen und Datenstrukturen 2
16. Ausnahmebehandlung Programmieren / Algorithmen und Datenstrukturen 2 Prof. Dr. Bernhard Humm FB Informatik, Hochschule Darmstadt Wintersemester 2012 / 2013 1 Agenda Kontrollfragen Motivation Fehlerbehandlung
MehrVorlesung "Verteilte Systeme" Sommersemester Verteilte Systeme. 9. Verteilte Algorithmen
Vorlesung "Verteilte Systeme" Sommersemester 999 Verteilte Systeme 9. Verteilte Algorithmen Bereits behandelte Bereiche Logische Uhren Keine globale Uhrensynchronisation möglich (Theorie) Kausalitätserhaltender
MehrVerteilte Betriebssysteme
Verteiltes System Eine Sammlung unabhängiger Rechner, die dem Benutzer den Eindruck vermitteln, es handle sich um ein einziges System. Verteiltes Betriebssystem Betriebssystem für verteilte Systeme Verwaltet
MehrVerteilte Systeme. Diffusionsalgorithmen. Secure Identity Research Group
Verteilte Systeme Diffusionsalgorithmen Diffusionsalgorithmen Definition: Ein verteilter Diffusionsalgorithmus auf einem Beliebigen Graphen startet in einem Zustand, in dem alle Knoten des Graphen idle
MehrVerteilte Algorithmen
Verteilte Softwaresysteme Verteilte Algorithmen Fakultät für Informatik und Mathematik Hochschule München Letzte Änderung: 18.06.2018 21:08 Inhaltsverzeichnis Verteilt versus zentralisiert 1 Unterschiede....................................
MehrVertrieb datentechnischer Geräte
Geschäftsführer: Buchwiese 16 Telefon: 0 61 26 / 93 60-0 Eingetragen: Nassauische Sparkasse Wiesbaden UST.-ID-Nr. Gerichtsstand für Voll- Jörg Alberti 65510 Idstein/Ts. Telefax: 0 61 26 / 93 60-90 Amtsgericht
MehrUmgang mit Fehlern. Sinn von Ausnahme-/Fehlerobjekten Dokumentation Umgang mit Fehlern Eigene Fehlerklassen
Umgang mit Fehlern Sinn von Ausnahme-/Fehlerobjekten Dokumentation Umgang mit Fehlern Eigene Fehlerklassen Die Java-Fehlerbehandlung stellt gegenüber älteren Verfahren einen großen Fortschritt dar. Prof.
MehrSoftware-Wartung eine Taxonomie
Software-Wartung eine Taxonomie Übersicht Warum wird eine Taxonomie der Software-Wartung benötigt? Definition der Software-Wartung Erläuterung verwandter Begriffe Arten und Aspekte der Software-Wartung
Mehr7.2 Journaling-File-Systems (4)
7.2 Journaling-File-Systems (4) Log vollständig (Ende der Transaktion wurde protokolliert und steht auf Platte): Redo der Transaktion: alle Operationen werden wiederholt, falls nötig Log unvollständig
MehrVerteilte Betriebssysteme
Andrew S. Tanenbaum Verteilte Betriebssysteme Prentice Hall München London Mexiko City New York Singapur Sydney Toronto Vorwort 1 Verteilte Systeme - Einführung 1.1 Was ist ein verteiltes System? 1.2 Ziele
Mehr2. Anforderungen an Automatisierungssysteme
Grundlagen der Automatisierungstechnik (Automatisierungstechnik 1) 2. Anforderungen an Automatisierungssysteme Anforderungen an Automatisierungssysteme Verlässlichkeit (Dependability) Zuverlässigkeit (Reliability)
MehrSoftware Engineering. 5. Architektur
Software Engineering 5. Architektur Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement
MehrÜberblick. Verlässliche Echtzeitsysteme. Annahmen. Table of Contents. Übungen zur Vorlesung. Florian Franzmann Martin Hoffmann Tobias Klaus
Überblick Verlässliche Echtzeitsysteme Übungen zur Vorlesung Florian Franzmann Martin Hoffmann Tobias Klaus Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und
MehrAufgabe 2.1: Lamports Uhren
Aufgabe 2.1: Lamports Uhren Die Relation a ereignet sich kausal vor b wird kurz als a b notiert. Von zwei Ereignissen a und b sind logische Zeitstempel nach Lamport, C(a) und C(b), bekannt, und es gilt
MehrWege zur Hochverfügbarkeit. Christian Affolter High Availability 08. Mai 2015
Wege zur Hochverfügbarkeit Christian Affolter High Availability 08. Mai 2015 Übersicht Weshalb Hochverfügbarkeit? Was ist Hochverfügbarkeit? Wege / Prinzipien / Konkrete Ansätze Herausforderungen und Erfolgsfaktoren
MehrHA Storage Cluster Lösung
@ EDV - Solution HA Storage Cluster Lösung hochverfügbar, flexibel, schlüsselfertig, kostengünstig, einfaches Management @ EDV - Solution Tel.: +43 (0)7612 / 62208-0 Fax: +43 (0)7612 / 62208-15 4810 Gmunden
MehrHA Storage Cluster Lösung
@ EDV - Solution HA Storage Cluster Lösung hochverfügbar, flexibel, schlüsselfertig, kostengünstig, einfaches Management 99,9% Verfügbarkeit klingt gut, reicht uns aber nicht! Seite 2 Fakten zählen, nicht
Mehr15. Ausnahmebehandlung Programmieren / Algorithmen und Datenstrukturen 2
15. Ausnahmebehandlung Programmieren / Algorithmen und Datenstrukturen 2 Prof. Dr. Bernhard Humm FB Informatik, Hochschule Darmstadt Wintersemester 2012 / 2013 1 Agenda Motivation Fehlerbehandlung Übung
Mehr4 Grundlagen von SQS-TEST/Professional New Line
4 Grundlagen von SQS-TEST/Professional New Line 4.1 Einführung SQS-TEST/Professional New Line (NL) ist ein umfassendes und flexibles Werkzeug für den Test von Softwareanwendungen. Eine Anwendung (z.b.
MehrFehlertoleranzmechanismen in hochverfügbaren Clustersystemen
Holger Sattel Seminar Rechnerarchitektur WS 2003/04 Universität Mannheim Lehrstuhl Rechnerarchitektur Prof. Dr. U. Brüning Inhaltsverzeichnis Grundlagen / Begriffe Fehlertoleranz Fehlertoleranz in (Rechen-)Clustern
Mehr13.1 Einführung. Fehler. Fehler (Forts.)
Verteilte Betriebssysteme Wintersemester 8/9 Verteilte Betriebssysteme. Kapitel Konsens Prof. Matthias Werner Professur Betriebssysteme. Einführung. Einführung Wir haben bereits einige Probleme betrachtet,
MehrHA Storage Cluster Lösung
@ EDV - Solution HA Storage Cluster Lösung hochverfügbar, flexibel, schlüsselfertig, kostengünstig, einfaches Management 99,9% Verfügbarkeit klingt gut, reicht uns aber nicht! Seite 2 Fakten zählen, nicht
MehrVerlässliche Echtzeitsysteme
Verlässliche Echtzeitsysteme Redundante Ausführung Fabian Scheler Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) www4.informatik.uni-erlangen.de
MehrIntern: Ceph Kurzeinführung in die verteile Storage-Lösung
Intern: Ceph Kurzeinführung in die verteile Storage-Lösung Dominik Vallendor 29.05.2017 Tralios IT GmbH www.tralios.de Motivation Lokale Speicher sind unflexibel, selbst mit Redundanzlösungen (bsp. DRBD)
MehrSoftware Entwicklung 2
1 Software Entwicklung 2 Softwareprüfung Prof. Dr. Liggesmeyer, 1 Inhalt System, technisches System Qualität, Qualitätsanforderung, Qualitätsmaß, Qualitätsmerkmal Sicherheit, technische Sicherheit Korrektheit,
MehrSIMATIC PCS 7 V6.1 SP1. Redundanz und Hochverfügbarkeit in PCS 7. Redundanz und Hochverfügbarkeit in PCS 7. Themen
SIMATIC PCS 7 V6.1 SP1 Redundanz und Hochverfügbarkeit in PCS 7 SIMATIC PCS 7 V6.1 + SP1 Siemens AG Folie 1 Einführung und Übersicht Prozessleitsysteme sind für die Steuerung, Überwachung und Dokumentation
MehrBrewer s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Sigact News, 33(2), June 2002
Brewer s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Sigact News, 33(2), June 2002 Seth Gilbert Nancy Lynch Brewer s Conjecture and the Feasibility of Consistent,
MehrIUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES Software AG. All rights reserved. For internal use only
IUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES 2016 Software AG. All rights reserved. For internal use only DIGITAL BUSINESS APPLICATIONS DRIVE THE DIGITAL BUSINESS Partner Lieferanten Kunden SaaS
MehrVerteilte Systeme. Verteilte Systeme. 7 Koordination SS 2017
Verteilte Systeme SS 2017 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 26. Juni 2017 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/12) i
MehrVerlässliche Echtzeitsysteme
Verlässliche Echtzeitsysteme Übungen zur Vorlesung Florian Franzmann, Martin Hoffmann Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) www4.informatik.uni-erlangen.de
MehrVS2 Slide 1. Verteilte Systeme. Vorlesung 2 vom Dr. Sebastian Iwanowski FH Wedel
VS2 Slide 1 Verteilte Systeme Vorlesung 2 vom 15.04.2004 Dr. Sebastian Iwanowski FH Wedel VS2 Slide 2 Inhaltlicher Umfang dieser Vorlesung Inhaltliche Voraussetzungen: Programmieren, Grundkenntnisse Java
MehrTest offener, dynamischer Systeme
Test offener, dynamischer Systeme Institut für Informatik Neuenheimer Feld 326 69120 Heidelberg http://www-swe.informatik.uni-heidelberg.de paech@informatik.uni-heidelberg.de RUPRECHT-KARLS-UNIVERSITÄT
MehrVerfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com
Verfügbarkeit von Applikationen und Failover Szenarien Winfried Wojtenek wojtenek@mac.com Verfügbarkeit % Tage Stunden Minuten 99.000 3 16 36 99.500 1 20 48 99.900 0 9 46 99.990 0 0 53 99.999 0 0 5 Tabelle
MehrVerlässliche Echtzeitsysteme
Verlässliche Echtzeitsysteme Redundante Ausführung Fabian Scheler Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) www4.informatik.uni-erlangen.de
MehrByzantinische Fehlertoleranz durch Gruppenkommunikation am Beispiel des Rampart-Toolkit
Byzantinische Fehlertoleranz durch Gruppenkommunikation am Beispiel des Rampart-Toolkit Frank Mattauch Frank.Mattauch@informatik.stud.uni-erlangen.de Kurzzusammenfassung Das Rampart-Toolkit ist ein Werkzeug,
MehrFehler und Fehlertoleranz
Fehler und Fehlertoleranz Begriffe und Techniken Perlen der Weisheit 8..000 Max Breitling Beispiele für Fehler: Unerwartet ausgelöste Airbags Schreibfehler in Spezifikationen Unerwarteter Systemfehler
MehrVerlässliche Echtzeitsysteme
Verlässliche Echtzeitsysteme Redundanz und Fehlertoleranz Peter Ulbrich Lehrstuhl für Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg https://www4.cs.fau.de 11.
MehrModellierung verteilter Systeme Grundlagen der Programm und Systementwicklung
Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Wintersemester 2009/10 Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. K. Spies, Dr. M. Spichkova, L. Heinemann, P.
MehrÜberblick. Verlässliche Echtzeitsysteme. Überblick. Annahmen. Übungen zur Vorlesung. 6. Juli 2015
Verlässliche Echtzeitsysteme Übungen zur Vorlesung Florian Franzmann Tobias Klaus Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) https://www4.cs.fau.de
MehrZeit als Mittel der Reihenfolgebestimmung
Uhrensynchronisation Notwendigkeit von Uhrensynchronisation Zeit als Mittel der Reihenfolgebestimmung Probleme der Uhrensynchronisation Lamport Vektorduhren Synchronisation von physikalischen Uhren Grundlagen
MehrVerteilte Systeme. Synchronisation II. Prof. Dr. Oliver Haase
Verteilte Systeme Synchronisation II Prof. Dr. Oliver Haase 1 Überblick Synchronisation 1 Zeit in verteilten Systemen Verfahren zum gegenseitigen Ausschluss Synchronisation 2 Globale Zustände Wahlalgorithmen
MehrTheoretische Grundlagen der Informatik. Vorlesung am 8. Januar INSTITUT FÜR THEORETISCHE INFORMATIK
Theoretische Grundlagen der Informatik 0 08.01.2019 Torsten Ueckerdt - Theoretische Grundlagen der Informatik KIT Die Forschungsuniversität in der Helmholtz-Gemeinschaft www.kit.edu Letzte Vorlesung Eine
Mehr(Ausnahmebehandlung)
16. Exceptions (Ausnahmebehandlung) 16-1 Objektorientierte Programmierung (Winter 2010/2011) Kapitel 16: Exceptions (Ausnahmebehandlung) Motivation Throw und Catch 16. Exceptions (Ausnahmebehandlung) 16-2
MehrVerteilte Systeme - Java Networking (Sockets) 2 -
Verteilte Systeme - Java Networking (Sockets) 2 - Prof. Dr. Michael Cebulla 06. November 2014 Fachhochschule Schmalkalden Wintersemester 2014/15 1 / 30 Michael Cebulla Verteilte Systeme Gliederung Wiederholung:
MehrNCP Secure Enterprise HA Server (Linux) Release Notes
Service Release: 10.01 r38360 Datum: Februar 2018 Linux Distributionen: Diese Version ist für die 64-Bit-Versionen folgender Distributionen freigegeben: SuSE Linux Enterprise Server 12 SP3 CentOS 7.4 Debian
MehrSYMPTOME U. a.: Wenn man nach der Datensicherung wieder mit dem ColorManager arbeiten will, kommt die Meldung. auf Deutsch oder.
Das Programm Backup On Stick verursacht immer öfter Fehlermeldungen von ColorManager, da die Datensicherung über nicht dokumentierte Wege außerhalb des SQL-Servers durchgeführt wird. Deshalb wird auch
MehrVerlässliche Echtzeitsysteme
Verlässliche Echtzeitsysteme Redundante Ausführung Fabian Scheler Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) www4.informatik.uni-erlangen.de
MehrExample Ptolemy Model of Comp.: Synchronous Reactive
Prinzip: Example Ptolemy Model of Comp.: Synchronous Reactive Annahme: unendlich schnelle Maschine Diskrete Ereignisse (DE) werden zyklisch verarbeitet (Ereignisse müssen nicht jede Runde eintreffen) Pro
MehrG DATA TechPaper. Update auf Version 14.1 der G DATA Unternehmenslösungen
G DATA TechPaper Update auf Version 14.1 der G DATA Software AG Application Development Q3 2017 Inhaltsverzeichnis Zusammenfassung & Umfang... 3 Typographische Konventionen... 3 Vorbereitung... 4 Update
MehrEntwicklung sicherheitskritischer Systeme
Entwicklung sicherheitskritischer Systeme Anforderungen der ISO 26262 an die Softwareentwicklung 569 Auswahl der Programmiersprache Bewertungen der Programmiersprachen in der IEC 61508 "++": Das Verfahren
MehrElectronic Design Automation (EDA) Spezifikation
Electronic Design Automation (EDA) Spezifikation Inhalte einer Spezifikation Beispielspezifikation Ampelsteuerung Formale Beschreibung Blockdiagramme... für die Ampel Zustandsübergangs-diagramme... für
MehrEinführung in parallele Dateisysteme am Beispiel von GPFS. Proseminar von Jakob Schmid im SS 2014
Einführung in parallele Dateisysteme am Beispiel von GPFS Proseminar von Jakob Schmid im SS 2014 Gliederung Definition Anwendungsgebiete Anforderungen Beispiel: General Parallel File System (GPFS) Zusammenfassung
Mehr4. Lernen von Entscheidungsbäumen
4. Lernen von Entscheidungsbäumen Entscheidungsbäume 4. Lernen von Entscheidungsbäumen Gegeben sei eine Menge von Objekten, die durch Attribut/Wert- Paare beschrieben sind. Jedes Objekt kann einer Klasse
MehrGrundlagen der Programmierung Prof. H. Mössenböck. 16. Ausnahmen (Exception Handling)
Grundlagen der Programmierung Prof. H. Mössenböck 16. Ausnahmen (Exception Handling) Motivation Fehler können nicht immer dort behandelt werden, wo sie auftreten void p() { q(); Lösung void q() { r();
MehrEinführung: Zustandsdiagramme Stand:
Einführung: Zustandsdiagramme Stand: 01.06.2006 Josef Hübl (Triple-S GmbH) 1. Grundlagen Zustandsdiagramme Zustände, Ereignisse, Bedingungen, Aktionen 2. Verkürzte Darstellungen Pseudozustände 3. Hierarchische
Mehr