Design Patterns für hohe Verfügbarkeit

Anbieter zum Thema

Hardware-Fehlertoleranz

Statt individuelle, hochzuverlässige Hardwaremodule aus hochzuverlässigen Komponenten zu bauen, ist es in den meisten Fällen kostengünstiger, Hardware und Komponenten handelsüblicher Qualität für die Redundanz zu verwenden.

Replikate sind oft so ausgelegt, dass sie Fail Fast bzw. Fail Stop unterstützen: Das Hardwaremodul hält quasi sofort an, wenn es einen Fehler entdeckt. So wird das Fehlermanagement bzw. die Entscheidungsfindung erheblich einfacher: Jeder Ausfall führt dazu, dass die Hardware sofort anhält, anstatt einfach „weiterzuhinken“ und den Fault Manager ermitteln zu lassen, welche Ausgänge des Moduls denn nun fehlerhaft sind und welche nicht.

Bei Fehlertoleranzverfahren mit statischer Redundanz genügt es, wenn die Replikate eine durchschnittliche Zuverlässigkeit aufweisen. Werden zwei Replikate verwendet, spricht man von „Pairing“ oder „Duplexing“ bzw. bei Einsatz von N Replikaten von „N-Plexing“.

Abbildung 1 zeigt ein Hardware-Design mit dreifacher Redundanz.

Die Ergebnisse der drei Replikate (im unteren Bildbereich) gehen zu einem „Voter“, der das endgültige Ergebnis dieses dreifach redundanten Systems bestimmt. In den meisten N-Plex-Systemen mit N>3 trifft der Voter eine Mehrheitsentscheidung. Dafür ist jedoch die Mehrheit der nicht ausgefallenen Replikate ausschlaggebend und nicht die Mehrheit der insgesamt vorhandenen Replikate (ausgefallene und nicht-ausgefallene).

Aber auch ein Voter ist letztlich nur eine Hardwarekomponente mit Software, und genau wie die anderen Module in unserem System könnte er ausfallen – allerdings mit gravierenden Auswirkungen. Die meisten Voter sind jedoch sehr einfache Komponenten und aufgrund ihres Designs und ihrer Testbarkeit sehr zuverlässig. (Eine andere Möglichkeit wäre es, Designs mit replizierten oder Second-Level-Votern etc. zu implementieren).

Auch für die Fehlertoleranz mit dynamischer Redundanz reicht es, wenn die Replikate eine durchschnittliche Zuverlässigkeit aufweisen. Die Module müssen keine 1:1-Kopien sein und können unterschiedliche Eigenschaften, Schnittstellen und Funktionen haben. Um die Verwaltung mehrerer Module zu steuern, wenn im Primärmodul ein Fehler auftritt, erfordert die dynamische Redundanz eine Failover-Strategie. Es bieten sich u.a. folgende Methoden an:

Standby-Backup: So lange das Primärmodul im System läuft, beobachtet ein Backup-Modul im Standby das Geschehen. Tritt im Primärmodul ein Fehler auf, ist das Backup-Modul sofort einsatzbereit und kann den Dienst übernehmen.

Rotating Standby: Im System läuft das Primärmodul, und es kann mehrere Backup-Module geben. Tritt im Primärmodul ein Fehler auf, springt eines der Backup-Module ein.

Failover to non-critical Module: Das Primärmodul führt die kritischen Systemressourcen aus. Ein Backup-Modul kann währenddessen andere, unkritische Dienste ausführen, im Fehlerfall aber auch die kritischsten Dienste des Primärmoduls übernehmen.

Mutual Takeover: Jedes Modul führt eigene kritische Dienste aus, kann aber im Fehlerfall die kritischen Dienste eines anderen Moduls übernehmen.

Eine fehlerfreie Implementierung ist dabei unerlässlich. Wenn ein Primärmodul trotz Fehler weiterläuft und ein anderes Modul gleichzeitig versucht, dessen Dienste zu übernehmen, könnten die Dienste der beiden Module mit unerwarteten Folgen kollidieren.

Dies könnte gravierende Auswirkungen haben, ebenso, wenn das Primärmodul im Fehlerfall anhält und kein anderes Modul seine Dienste übernimmt. Das Validieren und Prüfen der Failover-Implementierung hat demnach einen hohen Stellenwert – auch wenn diese Tätigkeit bei den meisten von uns nicht unbedingt beliebt ist.

(ID:44790372)