Design Patterns für hohe Verfügbarkeit

Anbieter zum Thema

MicroConsult Academy GmbH

Process Pair löst nicht alle Probleme

So ausgefeilt der Process Pair Ansatz auch ist, er berücksichtigt nicht alle Probleme. So kann es vorkommen, dass Checkpointing-Nachrichten verlorengehen oder unsortiert beim Backup-Server ankommen. Oder ein Primärserver, der ein physikalisches Gerät steuert, fällt mitten in einer Operation aus. Wenn der Backup-Server diese Operation übernimmt, wie kann er sie dann fertigstellen? (Beispiel: Der Primärserver hat vor seinem Ausfall die Graphitstäbe in einem Kernreaktor nur um 10 der erforderlichen 30cm bewegt).

Wie bereits angesprochen, kann es im Process Pair Ansatz durchaus vorkommen, dass die Transaktion, die bei Ausfall des Primärservers gerade ausgeführt wurde, verlorengeht oder mittendrin stehen bleibt. Der Backup-Server übernimmt dann in dem Zustand der letzten zuvor abgeschlossenen Transaktion, die ihm der Primärserver vor dessen Ausfall mitgeteilt hat.

Ein weiterer Ansatz der dynamischen Softwareredundanz ist das Recovery-Block-Konzept. Auch hier werden Checkpoints verwendet; darüber hinaus werden die Ergebnisse der Softwareverarbeitung noch einem Akzeptanztest unterzogen. Wie beim N-Version Programming sind mehrere verschiedene Datenverarbeitungsmethoden bereitzustellen, doch nicht alle dieser Methoden sind für jede Transaktion durchzuführen.

Stattdessen wählen Sie eine primäre Verarbeitungsmethode und führen dann die Transaktion nur mithilfe dieser primären Methode durch. Am Ende dieser primären Verarbeitung folgt der Akzeptanztest. Ist dieser erfolgreich, haben Sie es geschafft. Andernfalls versuchen Sie es mit der nächsten Verarbeitungsmethode, wie in Abbildung 4 dargestellt.

Das Checkpointing muss vor dem ersten Eintreten in den Recovery Block erfolgt sein, und die Software muss nach jedem nicht bestandenen Abnahmetest zurück in den Checkpoint-Zustand (Rollback).

Der Akzeptanztest wird nach jeder Verarbeitungsmethode durchgeführt. So werden alle möglichen Verarbeitungsmethoden ausgeführt, bis das Ergebnis einer Methode den Akzeptanztest besteht. Dies sind dann die „gültigen“ Ausgaben, die die Endergebnisse des Recovery Blocks beinhalten.

Checkpoint-Rollback, Process Pairs und Recovery Blocks sind Methoden der Rückwärts-Fehlerbehebung. Die Vorwärts-Fehlerbehebung ist ein weiteres Verfahren zur dynamischen Softwareredundanz. Dabei wird ein Prozess ab einem fehlerhaften Zustand weiter ausgeführt, und es werden Korrekturen vorgenommen, um den fehlerhaften Zustand zu beheben.

Die Vorwärts-Fehlerbehandlung erfordert eine hochpräzise Schadensbewertung und ist oft systemspezifisch. Ein Beispiel für die Vorwärts-Fehlerbehandlung ist das Exception Handling. Dabei wird die Steuerung einer speziellen Exception-Handling-Software übertragen, sobald ein Problem entdeckt wird, anstatt zurückzugehen und den Prozess ab diesem Punkt in einem vorher gesicherten Zustand weiter auszuführen.

Eine weitere Methode der Vorwärts-Fehlerbehebung ist das so genannte „Alternative Processing“. Sie ist hilfreich, wenn es für eine Transaktion zwei (oder mehr) Verarbeitungsalternativen gibt - eine meist hochpräzise aber sehr rechenintensiv und die andere einfacher aber leistungsfähiger. Die zweite Alternative kann als Test und zur Ermittlung von Sekundärergebnissen dienen, wenn die Primärverarbeitung fehlerhaft ist.

Beispielsweise könnte ein Quicksort-Algorithmus die primäre Verarbeitungsmethode und ein Bubblesort-Algorithmus die Alternative dazu sein. Nach Durchführung von Quicksort lassen sich mithilfe von Bubblesort die Quicksort-Ergebnisse prüfen und mögliche Quicksort-Fehler schnell beheben. Abbildung 5 zeigt ein weiteres Beispiel.

In dieser Abbildung sehen wir zwei gleichzeitig laufende digitale Flugleitsysteme zur Steuerung eines Flugzeugs (777). Die Entscheidungslogik rechts im Diagramm nimmt die Ergebnisse des einfacheren Flugleitsystems als „Maßstab“, gegen den die Ausgaben des komplexen Primär-Flugleitsystems getestet werden.

Wenn der Akzeptanztest fehlschlägt, ließen sich die Ergebnisse des einfacheren Flugleitsystems auch anstelle der fehlerhaften Ergebnisse aus dem Primärsystem verwenden. (Die Linkspfeile zeigen, dass die Ergebnisse des Alternative Processing auch als Feedback an die Primärverarbeitung dienen können).

Resümee

Nur mithilfe der hier besprochenen Methoden lassen sich Hardware und Software von durchschnittlicher bzw. handelsüblicher Qualität als Bausteine für hochverfügbare Systeme einsetzen – also Systeme, die ohne menschlichen Eingriff eine Verfügbarkeitsklasse 5 (99,999%) oder höher erzielen. Dies entspricht weniger als 1 Sekunde Ausfallzeit pro Tag über einen mehrjährigen Betrieb.

Dieses Paper bietet eine kurze Einführung in Themen rund um den Entwurf von hochverfügbaren Embedded-Systemen.

(Übersetzung: Sabine Pagler)

Designprozesse

Der dynamikrobuste Softwareentwurf

Wie wird aus Anforderungen eine Software-Architektur?

Echtzeit

Best Practices zur Lösung von Timing-Problemen

* *David Kalinsky ... ist Berater, Trainer und Dozent für Echtzeit- und Embedded-Programmierung in Sunnyvale/Kalifornien (USA).

(ID:44790372)