Introduction to Fault-Tolerance-Patterns

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.

Latent Fault

Faults können zu einem Error führen. Sie sind grundsätzlich in jedem System vorhanden, treten aber nicht unbedingt auf. In diesem Fall werden werden die Faults als latent bezeichnet.

Ein Error ist ein falscher Systemzustand, welcher einen „failure“ hervorrufen kann, aber nicht muss. Error werden in zwei Kategorien unterteil: Timing (z.B. Race Condition oder Endlosschleife) und Value (z.B. Dateninkonsistenz oder Wild Write -> Daten werden an einem falschen Ort geschrieben).

Beispiel: In unserem Beispiel mit dem Bankomat (siehe Failure) wäre der Error, dass die Banknoten im falschen liegen.

Bezeichnet ein System, das seine Spezifikationen nicht mehr befolgt. Ohne Spezifikation kann aber auch kein Failure statfinden.

Beispiel: Bei einem Bankomat wäre ein Failure, wenn ein falscher Betrag ausgegeben wird.

Andere Beispiele:

• Falsche Resultate werden geliefert
• System ist nicht erreichbar zu unerwartetem Zeitpunkt
• Applikation reagiert nicht auf Benutzereingabe

Fail-Silent (Fail Mode): Das System liefert entweder das korrekte, oder gar kein Resultat mehr.

Crash-Failure (Fail Mode): Nach einem fail-silent failure stürzt das Subsystem ab

Fail-Stop (Fail Mode): Der crash-failure ist für den Rest des Systems sichtbar.

Consistent Failures: Das System scheitert und für alle Beobachter erzeugt dies das selbe Resultat.

Inconsistent (Malicious) Failures: Der Fehler im System wird von veschiedenen Benutzern auf verschiedene Art und Weise erkannt.

Coverage ist die Fähigkeit eines Systems, wenn ein Fehler auftaucht, in einer gewissen Zeit zu automatisch zu korrigieren.

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.