Introduction to Fault-Tolerance-Patterns

Reliability ist die Wahrscheinlichkeit, dass ein System für eine gewisse Zeit ohne Failure läuft.

Availability, Verfügbarkeit, beschäftigt sich mit der prozentualen Zeit in welcher das System fehlerfrei arbeitet und verfügbar ist.

MTTF/(MTTF+MTTR) == MeanTimeToFailure / (MeantTimeToFailure + MeanTimeToRepair)

Dependability ist eine Kombination aus Reliabiliy, Availability, Safety und Security.

Safety: Nicht-Auftritt eines katastrophalen Failures

Security: Unerlaubter Zugriff oder unerlaubtes Verbearbeiten von Informationen

Performance und Reliability liegen nahe beieinander, z.B. wenn definiert werden muss, wie viele Requests ein System gleichzeitig verarbeiten soll, und was passieren soll wenn diese Zahl überschritten wird.

Mögliche Szenarien sind etwa dass das System zusammenbricht, oder dass die Leistung sinkt.

Fault kann zu Error führen, wobei mehrere Faults (nicht gleichzeitig) zum selben Error führen können.

Error kann zu Failure führen, wobei mehrere Errors (nicht gleichzeitig) zum selben Failure führen können.

Fault Tolerant Mindset beschreibt die Denkweise, welche immer hinterfragt, was alles in einer bestimmten Situation schief laufen kann.

Eine gute Qualität garantiert nicht die Fehlertoleranz eines Systems, da diese zwei Eigenschaften ähnlich sind, aber unabhängig voneinander.

Die Qualität einer Software beschreibt, wie lange eine Software fehler- und errorfrei ausgeführt werden kann. Ein qualitativ hochwertiges Programm erzeugt nur wenige Errors. Trotzdem muss bei der qualitativ hochwertigen Software erzeugte Error nicht zwingend harmlos sein.

Ein System soll möglich einfach gehalten werden. Denn mit erhöhte Komplexität erhöht sich auch die Menge an Faults.

Defensive Programmierung beruht auf der fehlertoleranten Denkweise, wobei der Code sich selber vor möglicherweise auftretenden Problemen schützt.

Nach dem Prinzip, dass jede Zeile Code mögliche Faults birgt, so kann durch Hinzufügen von Code zur Fehlerbehandlung ebenfalls wieder neue Faults dazukommen. 

Es gibt verschiedene Ursachen, welche die gespeicherten Daten verändern können (z. B. bei falscher Verwendung von Pointer). Deshalb ist bei Verwendung von Pointer Vorsicht geboten

Datenstruktur sollen immer so gewählt werden, sodass diese auf Korrektheit (Korrekte Werte und für Datenintegrität) überprüft werden können.

Die Lebensdauer von fehlertoleranten Systemen ist hoch, weshalb die Wartbarkeit eine wichtige Rolle spielt. Der Code sollte einfach geschrieben sein (z.B. kleine Methoden), sodass das Design stetig problemlos weiterentwickelt werden kann.

Dank Coding Standard kann man die Qualität der Software steigern. Dabei sollte man nicht zu viele Standards verwenden, da sich keiner über 100 Standards merken kann.

RAID (Redundant Array of inexpensive disks) beschreibt eine Technologie mehrere Disks zu kombinieren und die Daten absichtlich Redundant zu halten.

Testing und Verifikation ist wichtig für ein Fehlertolerantes System, da dadurch die Zuverlässigkeit einer Software sichergestellt werden kann.

Hierbei bei wird dem System absichtlich falsche Werte mitgegeben, um zu testen, ob das System in der Lage ist, einen Fehler korrekt zu behandeln.

Error Detection -> Error Recovery -> Error Migration -> Fault Treatment

Damit der Zeitliche Deadline nicht überschritten wird können Failure ausgegeben werden, wenn der Resultat bis dahin noch nicht berechnet wurde. Dieser Failure führt nicht zu einem katastrophalen Failure.

Example: Web Server (responses are desired very quickly, but if a request should take longer than specified it won’t result in a system failure)

Die Resultate müssen in einem Hard Real-Time-System spätestens bis zum zeitlichen Deadline berechnet worden sein. Sonst kann es zu einem katastrophalen Failure führen (z.B. bei einem Flugzeug).

High Realibility ist wenn ein System eine hohe availability und hohe Anforderung an Korrektheit hat. High Availability hohe Verfügbarkeitsanforderungen an das System.

Bestimmt wie viel Fehler in einer gewissen Anzahl von Funktionsaufrufen geschehen darf. Z.B. in einer Bank darf nur maximal 1 Transaktion fehlschlagen pro 100‘000 Transaktionen.

Ein Biespiel eines Stateful Systems ist das Telefonnetzwerk, welche über eine grosse Menge an Statuinformationen verfügt. Wenn ein Stateful System sein State verliert, verliert es auch die Fähigkeit weiterzuoperieren.

Beispiele für Stateless Systeme sind z.B. Webserver. Anfragen welche an den Webserver gesendet werden sind nicht mehr Teil vom aktuellen System.

External Observers sind Systeme welche unabhängig vom eigendlichen System laufen und den Status des Systems überprüfen. Hierbei wird unterschieden zwischen Systemen, dessen Daten „live“ überwacht wird und Systeme, dessen Daten periodisch überwacht wird.