Error Mitigation Patterns

Durch die Fault Correlation wurde festgestellt, dass der Error nicht aufgrund eines Hard- oder Softwarefehlers sondern aufgrund einer Ressourcen Überlastung ausgelöst wurde. Dies kann aufgrund zu vieler Anfragen oder wegen eines Memory-Leaks entstehen. Wie soll das System nun auf die Überlastung reagieren?

Je nach dem welche Ressource ausgenutzt ist (Memory, Hardware-Ressourcen, CPU) ist eine andere Lösungsstrategie gefordert. Da es keine Wunderwaffe für sämtliche Überlastungsprobleme gilt, muss pro konkretes Problem eine eigene Error Migitation Technik implementiert werden. Das System hat somit verschiedene Overload Toolboxdes, eine für jedes mögliche Überlastungsszenario.

Bei einer sehr hohen Belastung oder einer Überlastung stehen nicht mehr genügend Ressourcen zur Verfügung, so dass die Anfragen und der Maintenance-Task ausgeführt werden können (CPU).

Die Maintenance-Tasks (zuständig für Fault-Tolerance) sollte daher so entworfen werden, dass diese auch verzögert ausgeführt werden können. Bei normaler Auslastung können die Maintenance-Tasks sofort ausgeführt werden. Bei sehr hoher Belastung sollten weniger wichtige Maintenance-Tasks hinaus gezögert werden, bis genügend Ressourcen
zur Verfügung stehen (Motto: was nicht kaputt ist muss nicht repariert werden). Dadurch hat das System mehr Ressourcen für das Abarbeiten von Anfragen.

Es sollte sichergestellt werden, dass die Maintenance-Tasks nicht ewig aufgeschoben werden. Nach einer maximalen Zeit sollten sie dennoch zur Ausführung kommen. Zudem kann die hohe Auslastung auch aufgrund von Fehler in der Anwendung entstehen. Bleibt die Auslastung über lange Zeit hoch, sollte der someone in charge ggf. Massnahmen
ergreifen.

Congestion = dt. Anhäufung

Wenn ein System überlastet ist und bereits ein Error-Mitigation-Pattern (z.B. Deferrable Work) angewandt hat, kann es sein, dass die Ressourcen-Belastung dennoch nicht abnimmt.

Das System soll ein Feedback-Mechanismus verwendet. Während der hohen Auslastung des Systems können zusätzliche Informationen gesammelt werden. Mittels der Fault-Correlation kann die Auslastung mit den neuen Informationen neu bewertet werden. Die Bewertung kann ergeben, dass ein anderes Pattern für die Reduktion der Last
(z.B. Memory ausgelastet anstelle der CPU) geeigneter ist. Dadurch kann das alternative Pattern angewandt werden. Der Feedback-Loop dient dazu, dass die Situation stetig neu bewertet wird. Someone in charge ist ein geeigneter Akteur für den Strategiewechsel, da dieser den Überblick über das System hat.

Ist ein System überlastet und hat Ressourcen-Mangel, muss es eine Strategie für die Zuweisung der Ressourcen zu den Anfragen findet. Hierfür sollen die Anfragen gruppiert werden, nach Art, Priorität oder einem anderen Kriterium. Um Starvation zu vermeiden werden die wichtigsten Anfragen nicht prioritär behandelt.

Das System teilt den Ressourcen-Pool weiter auf, sodass pro Kategorie ein eigener Ressourcen-Pool existiert. Dadurch ist sichergestellt, dass jede Anfrage bearbeitet wird. Höher gewichteten Anfragen werden dadurch priorisiert, dass deren Pool über mehr Ressourcen verfügt. Dieses Verfahren stellt auch sicher, dass wenn eine Kategorie übermässig
viele Anfragen hat, dies sich nicht auf die Ressourcen der anderen Kategorien auswirkt.

Wenn ein System die Anfragen aufgrund mangelnder Ressourcen nicht bearbeiten kann, könnte es die zusätzlichen Anfragen einfach verwerfen. Dies hat den Nachteil, dass Anfragen mit Unteranfragen (z.B. Download eines Files) verworfen werden und dadurch die gesamte Anfrage wiederholt wird, was zu höherer Systembelastung führt.

Aus diesem Grund soll das System eine Queue mit limitierter Grösse verwendet werden. Die Limitierung der Grösse stellt sicher, dass die Queue nicht auf eine Grösse anwächst, wo die neusten Anfragen auch bei optimaler Abarbeitung nicht mehr rechtzeitig zum Zug kommen. Die Queue kann nach dem FIFO oder LIFO Prinzip organisiert werden.

Bei Systemanfragen sollte eine FIFO-Queue verwendet werden, sodass sämtliche Anfragen abgearbeitet werden. Bei Benutzeranfragen sollte eine LIFO-Queue verwendet werden, das führt dazu, dass neue Anfragen möglichst schnell abgearbeitet werden. Ältere Anfragen werden weiter hinausgezögert, in der Annahme, dass die meisten Benutzer
sowieso bereits eine neue Anfrage gestellt haben (Browser F5 nach 4 Sekunden). Dadurch werden die Anfragen von denjenigen, welche voraussichtlich bereits aufgegeben haben nicht unnötigerweise (sofort) bedient.

Erkennt ein System einen Fehler, kann diesen aber nicht selbst beheben, dann sollte es die Daten als falsch markieren. Dadurch erspart es den anderen Systemen den Error-Check und dieses kann den Fehler ggf. korrigieren. Ein Beispiel hierfür ist NaN, welches ungültige Zahleneingaben markiert. Für die Markierung kann ein zusätzliches Feld verwendet
werden, welches vor jedem Zugriff geprüft werden muss (umständlich). Alternativ kann auf Value-Ebene ein weiterer Wert eingeführt werden für ungültige Werte (NaN). Hierbei muss definiert werden, wie sich das System verhalten muss, wenn mit einem solchen Wert gearbeitet wird.

Das System soll sicherstellen, dass die Daten korrekt sind. Falls die Daten korrupt sind, sollten diese ggf. korrigiert werden können.

Hierfür kann das System Checksummen verwenden, welche eine Korrektur einiger Bits ermöglichen.

Wenn ein System kurz vor der Überlastung steht, können entweder die Anfragen reduziert/verworfen werden, oder die verfügbaren Ressourcen werden erhöht. Expansive Automatic Controls hat das Ziel die zur Verfügung stehenden Ressourcen zu erhöhen.

Im Normalfall dürfen diese Ressourcen nicht genutzt werden, in Ausnahmesituation ist die Nutzung jedoch erlaubt.
Ein Beispiel aus dem Alltag ist, dass die Polizei bei zu starker Überlastung oder einen Unfall zusätzliche Strassen, welche ansonsten für Fahrzeuge gesperrt sind, freigegeben werden können. Dadurch gibt es mehr Ressourcen (Strassen) für die Abwicklung der Anfragen (Fahrzeuge).

In ein System sollten zusätzliche zuschaltbare Ressourcen eingeplant werden, welche bei starker Auslastung dazugeschalten werden können.

Kontext
 Das System erhält zu viele Request für seine beschränkten Resourcen.

Problem
 Wenn alle Ressourcen ausgelastet sind, benötigt es zusätzlichen Overhead um die noch Vorhandenen aufzuteilen. Dieser Overhead kombiniert mit der nicht abnehmender Last kann zum Systemkolaps führen.

Lösung
 Das System soll sich sich gegen aussen abschotten um sich vor der Übelast zu schützen. Dies kann bedeuten, dass Alles, was nicht verarbeitet werden kann, verworfen wird (SHED LOAD). Eine weitere Möglichkeit das System zu schützen ist routine Aufgaben auf später zu verschieben, so dass das System nicht zusätzlich belastet wird (DEFERRABLE WORK).Das Ziel dieser Schutzmassnahmen ist, dass das System nicht an der Überlast zusammenbricht und weiterhin Request verarbeiten kann.

Shed Load ist ein Beispiel für Protective automatic controls. Hierbei akzeptiert das System nur soviele Anfragen wie es selbst abarbeiten kann (restliche Anfragen werden verworfen). Dadurch wird versucht, dass System auf dessen maximalen Durchsatz zu betreiben, ganz nach dem Prizip "Qualität, nicht Quantität".

Bei der Abarbeitung werden Ressourcen wie File-Handles, Heap-Memory, Sockets etc. reserviert. Nach der Abarbeitung der Anfrage werden diese Ressourcen wieder freigegeben. Tritt bei der Verarbeitung jedoch ein Fehler auf, dann müssen diese Ressourcen auch freigegeben werden, ansonsten stehen diese für weitere Anfragen nicht mehr zur
Verfügung.

Die Ressourcenverwaltung sollte in den normalen Programmfluss integriert werden, sodass diese beim Fehlerfall und im normalen Fall korrekt freigegeben werden. Beispiel, verwenden von try-finally.

Wenn das System überlastet ist kann es durch die Verzögerung der Request-Annahme eine deeskalation vornehmen. Hierfür soll dass System eine mehrstufige Eskalationsstrategie verwenden. Je mehr Anfragen ankommen, desto restriktiver wird das System mit der Annahme von neuen Anfragen.

Es ist wichtig, dass der Threshold zwischen diesen einzelnen Eskalationsstufen genügend gross ist, ansonsten verwendet das System viel Zeit um zwischen den Eskalationsstufen umzuschalten.

Wenn Anfragen erst im Kernel des Systems verworfen werden, da die Ressourcen nicht ausreichend, wird auch viele bereits geleistete Arbeit verworfen. Daher sollten Anfragen so früh wie möglich im System verworfen werden. Beispielsweise sollten DDos Anfragen möglichst bei der Firewall bereits verworfen werden, wodurch das System nicht unnötig belastet wird.

Ein System ist überlastet und es gibt zusammengesetzte Anfragen, welche für den Client nur als ganzes abgearbeitet werden. Das System verwendet Shed Load und muss entscheiden, welche Anfragen zu verwerfen sind. Um nicht bereits erledigte Arbeit zu verwerfen, sollten Anfragen welche auf vorherigen Anfragen bestehen nicht weggeworfen werden, da ansonsten die gesamte Anfrage erneut gestellt wird. Das System soll daher eingehende Anfragen nach «neu» und «fortsetzung» kategorisieren. Anfragen die eine «Fortsetzung» von bestehenden Anfragen sind, dürfen nicht verworfen werden. Von den neuen Anfragen sollte noch eine geringe Anzahl akzeptiert werden, um zu verhindern, dass das System ansonsten in einen IDLE Zustand gerät, sobald sämtliche bestehenden Anfragen abgearbeitet wurden.

Fresh Work Before Stale (Stale = dt. abgelaufenes Scheck, gemeint ist hier ein abgelaufener Request)

Das System ist überlastet und Clients haben die Möglichkeit Anfragen neu zu starten. Dauert es in einem solchen System zu lange bis die Antwort den Client erreicht, wird dieser die Anfrage neu starten, in der Hoffnung, dass diese sofort abgearbeitet wird. Für das System bedeutet dies unnötige Last. Da aufgrund der Überlastung die Nachrichten bereits gequeued werden, bedeutet dies, dass durch das System viele bereits abgearbeitete Anfragen noch bearbeitet werden und neue Anfrage erst spät abgearbeitet werden.

Aus diesem Grund sollte für die Verarbeitung eine LIFO Queue (oder Mischung aus FIFO und LIFO) verwendet werden. Dies stellt zumindest sicher, dass neue Anfragen möglichst schnell, unter Einhaltung der Anforderungen, abgearbeitet wird. Sobald die Auslastung des Systems sinkt, wird dieses auch die meist sowieso bereits abgebrochenen Anfragen bearbeiten. Dies ist jedoch nicht so relevant, da die Systemlast zu diesem Zeitpunkt bereits gesunken ist.