Architectural Patterns

Fehler in Daten können durch Hardwarefehler (Memory Corruption), Anwendungsfehler oder durch Zufall entstehen. Daten-Fehler verbreiten sich schnell in einem System und je länger diese bestehen desto schwerer wird die Korrektur. Aus diesem Grund sollten falsche Daten so früh wie möglich erkannt und korrigiert werden.

Aus diesem Grund sollten Daten auf deren Korrektheit geprüft werden (Validation).

Die Daten sollten schnellst möglich korrigiert werden. Es gibt vier mögliche Prüfungen:

• "Check structural properties" Prüfen der Struktur. Beispiel Korrektheit der Links in einer Linked-List Prüfen, Pointers korrekt?
• "Known correlations" Wenn die Daten in verschiedenen Formaten gespeichert wird, kann mittels Umrechnung geprüft werden, ob die Daten korrekt sind.
• "Sanity Checks" (Plausibilitäts check) Prüfen ob die Werte sich in einem möglichen Wertebereich befinden (z.B. Alter). Eine Möglichkeit ist auch die Prüfung der Checksumme. Stimmt diese, dann sind die Daten voraussichtlich korrekt.
• "Direct Comparison" Führen von Redundanten Daten und diese zu einem späteren Zeitpunkt 1:1 vergleichen. Meistens nur bei statischen Daten sinnvoll.

Die Error-Behandlung in einem System benötigt einige Zeit und die Verfügbarkeit der Mitigation Unit ist dadurch beeinträchtigt. Um die Verfügbarkeit einer Mitigation Unit möglichst hoch zu halten, sollte die Fehlererkennung möglichst schnell ausgeführt werden (die Benachrichtigung kann auch noch im Hintergrund stattfinden).

Um von der Erkennung eines Errors über die Fehlerbehandlung möglichst schnell wieder in den Normalbetrieb gewechselt werden kann, sollten redundante Instanz bereitgestellt werden. Bei der redundanten Instanz kann es sich um Hardware oder Software handeln und muss nicht identisch mit der betroffenen Unit sein. Die Unit darf nicht vom selben Error betroffen sein und stellt ein alternatives Verfahren für die Zielerreichung dar.

Es gibt verschiedene Arten von Redundanzen:

• Spartial redundancy
  Spartial redundancy Es gibt mehrere redundante Kopien die räumlich an unterschiedlichen Orten laufen. Beispielsweise kann ein Mainboard eine reserve-CPU anbieten, welche beim Ausfall zugeschaltet wird. Oder die Berechnung erfolgt auf mehreren Implementierungen (N-Version-Programming).
• Temporal redundancy
  Temporal redundancy Bei Software-Komponenten können z.B. unterschiedliche Algorithmen oder Programme für die Lösung eines Problems verwendet werden. Schlägt die Sortierung mittels Merge-Sort fehl, kann eine Sortierung mittels Bubble-Sort versucht werden. Die Ausführung der Algorithmen geschieht nach einander.
• Informational redundancy
  Beifügen von Redundanten mittels welchen Fehler erkennt und behoben werden können. CRC-Prüfsummen, Errorcorrection-Codes.

Arten - Es gibt verschiedene Arten von redundanten Kopien

• Active-Active
  Beide Instanzen sind aktiv und synchronisieren in regelmässigen Abständen ihren Zustand. Bei einem Ausfall kann die die eine Instanz die Anfrage der anderen Instanzen sofort übernehmen, wobei ggf. ein Leistungseinbruch zu verzeichnen ist (z.B. Load-Balancing)
• Active-Standby
  Es gibt zusätzlich eine Komponente in Standby, welche den Zustand der aktiven Komponente repliziert (synchronous replication). Bei einem Ausfall wird die standby Komponente zur aktiven Komponente.
• N+M
  Entspricht dem Active-Standby, jedoch gibt es nicht für jede aktive Komponente eine Passive Komponente (Kostengründe).

Wenn die Behandlung eines Errors keine Wirkung zeigt, wie soll das System dann versuchen den Error zu beheben? Mögliche Ansätze sind das Wiederholen der Korrektur, was jedoch zu einem Endlosloop führen kann. Alternativ kann das Modul isoliert werden und ein eingeschränkter Betrieb angeboten werden.

Gemäss Escalation sollte zuerst eine möglichst spezifische Fehlerbehandlung verwendet werden. Funktioniert diese nicht, dann sollte eine allgemeinere Fehlerbehandlung versucht werden. Dieses Verfahren wiederholt sich, bis das Problem gelöst werden konnte. Tritt bei einer Datenbank-Abfrage ein Timeout auf, kann als erstes versucht werden die Abfrage erneut aus zu führen. Funktioniert dies nicht, dann kann versucht werden, die Abfrage mittels einer neuen Verbindung durch zu führen. Funktioniert auch dies nicht kann das System den Benutzer informieren (höchste Schicht).

Die Eskalation erfolgt somit Schrittweise.

Recovery Blocks ermöglichen eine Temporal-Redundancy. Beispielsweise stehen verschiedene Algorithmen für die Sortierung zur Verfügung. In einem ersten Schritt erfolgt die Sortierung mittels einem optimierten Algorithmus (Heap Sort). Schlägt dieser fehl, kann ein alternativer Algorithmus (Bubble Sort) verwendet werden. Das Pattern schlägt somit vor, dass mittels verschiedenen Lösungsvorgängen ggf. an das korrekte Resultat gekommen werden kann. Erst wenn sämtliche Verfahren fehlschlagen, sollte das Error Handling ausgelöst werden.

Der Vorteil dieses Verfahren ist, dass kein Overhead existiert, solange kein Error erkannt wird. Zudem nimmt die Komplexität der folgenden Algorithmen meist ab, da diese eine schlechtere Laufzeit haben, dafür meist toleranter sind.

Da für die verschiedenen Algorithmen immer mit den selben Ausgangsdaten gerechnet werden muss, ist das Erstellen von CHECKPOINTS notwendig. Durch die Erstellung des CHECKPOINTS werden die Daten gesichert, zu welchen mittels einem Rollback wieder zurückgekehrt werden kann.

Der Fault-Observer wird von den Systemen bei Errors sowie Failures benachrichtigt wie auch über die vorgenommenen Korrekturen. Beim Fault-Observer können sich Interessenten registrieren, welche beim eintreten der von ihnen definierten Ereignissen benachrichtigt werden. Der Fault-Observer observed die Systeme. Die Interessenten können sich mittels Publish-Subscribe-Pattern beim Observer registrieren und werden benachrichtigt.

Bei den Interessenten kann es sich z.B. auch um die someone in charge, Logging oder Redundante Komponenten handeln. Wird ein Error gemeldet, sollten auch die zugehörigen Faults gemeldet werden, dadurch wird der Kausalzusammenhang ggf. ersichtlich.

In jedem Software sind Faults enthalten, welche behoben werden müssen. Hierfür muss das System einen Update-Mechanismus anbieten, mit welchem das System aktualisiert werden kann. Die Aktualisierung sollte möglichst automatisch erfolgen (prozedurale Fehler vermeiden) und eine minimale Down-Time zur Folge haben. Der Update-
Mechanismus muss bereits mit der ersten Version verfügbar sein.

Folgend werden die möglichen Update-Verfahren erläutert:

• Vollständiges Update
  Neue Version des gesamten Systems. Die alte sowie neue Version kann nicht parallel betrieben werden, da sie die selbe Infrastruktur verwenden. In diesem Fall muss das alte System gestoppt werden und dann wird das ganze System aktualisiert. Dies führt zu einer planned Downtime.
• Paralleler Betrieb
  Die neue und alte Version können parallel Betrieben werden. Die neue Version wird bereits installiert. Nach der Installation erfolgt die Konfiguration, dass neue Anfrage an die neue Version umgeleitet werden. Sobald sämtliche Anfrage auf das neue System gehen, kann die alte Version gestoppt werden.
• Small Patch
  Einzelne Teile eines Systems können mittels Patches aktualisiert werden. Dadurch entsteht ein minimaler Unterbruch, welcher vom Benutzer meist nicht wahrgenommen werden kann. Diese Möglichkeit benötigt jedoch Infrastruktur, welche eine solche Aktualisierung im laufenden Betrieb erlaubt.

Kann die Anwendung nicht atomar aktualisiert werden, dann muss das System fähig sein mit älteren Versionen zu arbeiten. Hierfür wird in der Regel ein Versions-Parameter verwendet. Für die älteren Versionen kann eine Vorwärtskompatibilität erreicht werden, in dem neue Attribute ignoriert werden.

Failures können jederzeit auftreten. Dies ist auch bei der Error-Behandlung möglich, wodurch das System ggf. endgültig gestoppt werden kann.

Daher gibt es für jeden Vorgang im System «someone in charge». Bei einem Methodenaufruf ist z.B. der Aufrufer in Charge. Die Komponente «in charge» ist in einem Fehlerfall zuständig, die weitere Ausbreitung des Failures zu vermeiden. Je nach Art des Fehlers ist eine andere Eskalation angebracht. Innerhalb einer verteilten Anwendung
können die einzelnen Nodes füreinander zuständig sein.

Die Schwierigkeit am Pattern ist, dass auch für die someone in charge Komponente wiederum eine andere Komponente in charge sein muss (Rekursion!).

Bei prozeduralen Fehler handelt es sich um Fehler, welche durch Fehlverhalten von Menschen verursacht werden (Prozesse werden nicht eingehalten). Die Menschen neigen zu Fehler, da die Aufmerksamkeit bei repetitiven Aufgaben sinkt oder sie von Informationen/ Entscheiden überflutet werden.

Aus diesem Grund sollte ein System so entworfen werden, dass möglichst viele Errors ohne Einfluss von Aussen erkannt und behandelt werden können. Es sollte möglichst viele Schritte selbst vornehmen. Während der Fehlerbehandlung sollte der Benutzer über den Zustand und Fortschritt des Systems benachrichtigt werden.

Ist dennoch das Eingreifen des Benutzers notwendig, dann sollten diesem sämtliche relevanten Informationen dargestellt werden. Zudem sollte seine Aufmerksamkeit umgehend auf das Problem gerichtet werden. Sind mehrere Schritte notwendig, dann sollte der Benutzer geführt werden, am Besten nimmt das System die Schritte jedoch selbst vor.

Die Umsetzung sollte darauf achten, dass sämtliche Errors beim Fault-Observer gemeldet werden, dieser stellt sicher, dass sämtliche Systemüberwacher informiert werden.

Obwohl Menschen dazu neigen Fehler zu begehen, können sie zusätzliches Wissen mitbringen, welches bei der Fehlerbehandlung helfen kann. Dadurch kann der Mensch gewisse Probleme schneller oder auch besser lösen. Aus diesem Grund kann es sinnvoll sein, Experten in die Fehlerbehandlung mit ein zu beziehen. Die Experten verfügen meist
auch über Fachwissen. 

Das System bietet dem Benutzer die notwendigen Informationen, damit dieser bei Errors oder Faults eingreifen kann. Die Informationen können mittels dem Fault-Observer bereitgestellt werden. Der Zugriff erfolgt über ein Maintenance Interface. Die Human Participation muss bei jedem System abgewogen werden. Bei Alltagsgeräten ist der Benutzer
meist kein Experte und sollte daher so wenig wie möglich eingebunden werden. 

Im Gegensatz ist ein Pilot durchwegs ein Experte und kann bei der Behebung eines  Problems ggf. schnell helfen.

Der Nachteil des Vorgehens ist, dass der Mensch immer noch Fehler machen kann.

• Safe Mode
  Ein System kann in den Safe Mode wechseln. In diesem führt es keine weiteren Aktionen aus und wartet auf die Behebung der Situation durch den Benutzer. Angebracht wenn durch das Weiterfahren Schäden entstehen können.
• Root Cause Analysis
  Nach der Behebung des Errors sollte eine Root Cause Analysis durchgeführt werden. Falls der Fault auch automatisch behoben werden könnte, kann das System für diese Art von Faults erweitert werden, wodurch der Mensch entlastet wird.

Für die Durchführung von Wartungsarbeiten benötigt ein System ein Maintenance-Interface. Dieses sollte auch dann verfügbar sein, wenn die Anwendung selbst nicht verfügbar ist. Aus diesem Grund sollten diese Separat betrieben werden (Bei zu hoher Last kann das Maintenance-Interface z.B. höhere Priorität erhalten).

Die Trennung reduziert auch das Sicherheitsrisiko, dass versehentlich Wartungsbefehle ausgeführt werden. Beispiele: Router Management-Interface.