Design Patterns für hohe Verfügbarkeit

Anbieter zum Thema

MicroConsult Academy GmbH

Software-Fehlertoleranzverfahren

Es gibt etliche Software-Fehlertoleranzverfahren, die auf dynamischer Redundanz basieren und dabei einen vierstufigen Ansatz verwenden:

• 1. Fehlererkennung

• 2. Schadenseinschätzung und -begrenzung (Firewall)

• 3. Fehlerbehebung

• 4. Fehlerbehandlung und Fortführen des Dienstes

In der zweiten Stufe wird häufig ein Fail Stop ausgelöst, wenn ein Softwarefehler erkannt wird. Angesichts der Komplexität von Software ist aber oft unklar, wie sich die Auswirkungen fehlerhaften Softwareverhaltens beheben lassen.

Hier ist das Transaktionskonzept äußerst hilfreich. Eine Transaktion ist eine Folge von Operationen in einer Applikation. Zu Beginn und zu Ende einer Transaktion sind befindet sich die Applikation in einem konsistenten Zustand.

Wird zur Fehlertoleranz das Transaktionskonzept eingesetzt, muss unser System in der Lage sein, seinen Zustand zu Beginn einer Transaktion zu sichern; dies wird als „Checkpointing“ (Sicherungspunkt) bezeichnet. Dabei entsteht sozusagen ein Abbild des Softwarezustands genau zu dem Zeitpunkt, an dem der erste Schritt der nachfolgenden Transaktion beginnt. Das Abbild wird nur erstellt, wenn die vorangegangene Transaktion in fehlerfreiem Zustand abgeschlossen wurde.

Fehler werden hier durch erneute Ausführung behoben: Wird während einer Transaktion ein Fehler entdeckt, hält die Transaktion an (Fail Stop) und das System geht zum zuletzt gespeicherten Checkpoint zurück. Dann wird der Dienst ab diesem Checkpoint weiter ausgeführt, und weitere Transaktionen können in einem konsistenten Zustand ablaufen.

Die mittels Fail Stop angehaltene Transaktion geht dabei jedoch verloren. Dieses Verfahren bezeichnet man als Rückwärts-Fehlerbehebung: Der Softwarezustand wird in einen vergangenen, fehlerfreien Zustand zurückgeführt.

Auch dieses Verfahren hat eine fatale Schwachstelle (Single Point of Failure) - beim Erstellen des Abbildes könnte ein Fehler auftreten. Dies lässt sich jedoch über das so genannte „Checkpoint-Rollback“ vermeiden, wie in Abbildung 2 gezeigt.

In dieser Abbildung stellen die Ellipsen einen Software-Client und einen Software-Server dar, die miteinander kommunizieren, indem sie Messages über Queues verschicken. Eine Transaktion kann viele Anforderungen (Request Messages) und Antworten (Response Messages) enthalten. Während einer Transaktion ändern sich die Daten innerhalb des Servers.

Am Ende einer Transaktion sollte jeder der beiden persistenten Massenspeicher (rechts im Bild) einen konsistenten Datensatz zusammen mit einer Transaktionssequenznummer aufgezeichnet haben. Falls zu einem späteren Zeitpunkt ein Fehler entdeckt und die Serversoftware angehalten wurde, wird dieser Server (oder ein Reserve-Server) neu gestartet. Im Zuge der Wiederherstellung werden die Transaktionssequenznummern in den beiden Massenspeichern geprüft.

Die Serverdaten werden über den Speicher wiederhergestellt, der die höchste Sequenzzahl enthält. (Der andere könnte eine niedrigere Sequenzzahl haben, falls während des Checkpointing zu diesem Speicher ein Fehler vorlag).

Die Wiederherstellung nach einem Fehler kann beim Checkpointing lange dauern. Der Server-Start bzw. -Neustart und die Wiederherstellung der Daten ab dem Checkpoint sind unter Umständen mit hohem Verarbeitungsaufwand verbunden. Ein „Hot-Backup“-Server mit einem eigenen persistenten Massenspeicher könnte diesen Vorgang beschleunigen; dieses Konzept bezeichnet man auch als „Process Pair“, siehe Abbildung 3.

In der Mitte der Abbildung sehen wir einen “primären” Server, der im Großen und Ganzen wie im vorherigen Checkpointing-Szenario läuft. Die Clients arbeiten direkt mit diesem primären Server zusammen. Nach erfolgreichem Abschluss einer gesamten Transaktion schickt der Primärserver hier jedoch Daten über seinen neuen, konsistenten Zustand an einen Backup-Server (rechts). Sowohl der Primär- als auch der Backup-Server zeichnen diese Daten in ihrem persistenten Massenspeicher auf.

So bleibt der Backup-Server hinsichtlich der abgeschlossenen Transaktionen aktuell. Der primäre Server steht den Clients zur Verfügung und schickt dabei regelmäßig Heartbeat-Nachrichten an den Backup-Server. Diese Hearbeat-Nachrichten können zusammen mit Checkpointing-Nachrichten geschickt werden. Bleiben diese Nachrichten aus, erkennt der Backup-Server, dass der primäre Server ausgefallen bzw. nicht verfügbar ist und springt schnell als neuer primärer Server ein.

(ID:44790372)