Ein Angebot von

Zuverlässigkeit

Design Patterns für hohe Verfügbarkeit

| Autor / Redakteur: David Kalinsky* / Franz Graser

Durchgängig geöffnet: Hohe Verfügbarkeit von eingebetteten und vernetzten Systemen hängt von einer Vielfahl von Faktoren ab, darunter Hardware-Redundanz sowie softwarebasierten Fehlertoleranzverfahren.
Durchgängig geöffnet: Hohe Verfügbarkeit von eingebetteten und vernetzten Systemen hängt von einer Vielfahl von Faktoren ab, darunter Hardware-Redundanz sowie softwarebasierten Fehlertoleranzverfahren. (Bild: gemeinfrei/Pixabay / CC0)

Hochverfügbare Systeme müssen sowohl mit erwartbaren als auch mit unerwarteten Fehlern zurechtkommen können. Dieser Beitrag bespricht sowohl Hard- als auch solftwarebasierte Tolerenz und die Implementierung diverser Verfahren zur Steigerung der Fehlertoleranz.

Ein System gilt dann als hochverfügbar, wenn es sowohl erwartete als auch unerwartete Fehler tolerieren kann, basierend auf einer Kombination aus redundanten Hardwarekomponenten und Software zur Fehlererkennung und -beseitigung. Dies muss ohne menschlichen Eingriff erfolgen, damit eine Verfügbarkeitsklasse 5 (99,999%) oder höher erzielt wird. Dies entspricht weniger als 1 Sekunde Ausfallzeit pro Tag.

Dieser Beitrag stellt zunächst Definitionen zu Hochverfügbarkeit und Fehlermanagement sowie grundlegende Themen wie N-Plexing und Voting vor. Er betrachtet Software-Fehlertoleranzverfahren für Embedded-Systeme sowie die statische Methode N-Version Programming.

Ebenso werden verschiedene dynamische Software-Fehlertoleranzverfahren einschließlich Checkpoint-Rollback, Process Pairs und Recovery Blocks sowie „Alternative Processing“ als Verfahren zur Fehlerbehebung besprochen. Der Beitrag enthält viele praktische Anwendungsbeispiele.

Definitionen

Beim Entwurf eines hochverfügbaren Systems gilt es, sich insbesondere „Failures“, also Ausfälle bzw. Störungen, sowie „Faults“ (zugrundeliegende Fehler) zu widmen.

“Failure” lässt sich als Situation definieren, in welcher der von einem System erbrachte Dienst nicht der Spezifikation entspricht. Ich würde eine Definition vorziehen, die den von einem System erbrachten Dienst in Zusammenhang mit unseren Erwartungen an das System stellt. Da unsere Erwartungen jedoch häufig subjektiv sind und oft nicht ausreichend dokumentiert, bleiben wir also bei den Diensten eines Systems im Verhältnis zur Spezifikation - auch wenn diese Definition Probleme, die auf Fehler oder Auslassungen in der Spezifikation selbst zurückzuführen sind, nicht berücksichtigt.

Ein “Fault” dagegen ist der Ausfall (Failure) eines interagierenden Systems. Wir verstehen unter Fault die mögliche „Ursache“ eines (nicht erwünschten) Ereignisses. Ein Fault kann also der Ausfall (Failure) eines Subsystems in unserem System, einer Komponente oder eines externen Systems oder auch ein Programmierfehler sein. Ein Fault kann weitere, unterschiedlich geartete Faults nach sich ziehen. Und er kann (muss aber nicht) auch Ausfälle (Failures) zur Folge haben.

Beispiel: Wenn ein LKW-Fahrer die Lastbegrenzung der Golden Gate Bridge nicht beachtet, wäre dies ein Fault. Überschreitet der LKW diese Begrenzung um 20 oder 30 Prozent, führt dies vermutlich nicht zu einem Ausfall bzw. Versagen der Brücke. Wenn dieser LKW auf der Brücke an den Fahrbahnteiler prallt, wäre das ein weiterer Fault, der aber auch zu keinem physikalischen Versagen der Brücke führen würde. Dennoch wäre die Brücke dann nicht mehr in der Lage, ihren spezifizierten Dienst mehrere Stunden lang zu erbringen, d.h. Personen und Fahrzeuge über die Golden Gate Bucht zu führen (Failure).

Es gibt temporäre, permanente oder sporadische Fehler (Faults). Diese können einen Zustandsfehler (Error) in einem System oder Subsystem verursachen. Und genau diese „Errors“ lösen u.U. einen Ausfall (Failure) Ihres Systems aus. Zur Behandlung von Fehlern (Faults) gibt es vier Ansätze:

  • Prognose
  • Vermeidung
  • Behebung
  • Maskierung

Fehlervermeidung und -behebung lassen sich durch strikte System-, Hardware- und Software-Entwicklungsprozesse umsetzen, ggf. im Zusammenspiel mit formaler Spezifikation und Verifikation. Fehlermaskierung bzw. „Fehlertoleranz“ kann über eine redundante und ggf. unterschiedliche Implementierung eines Systems realisiert werden. Eine Methode zur Schaffung von Fehlertoleranz ist Graceful Degradation bzw. Fail Soft (sanfte Leistungsminderung): Wichtige Teilfunktionen werden auch dann ausgeführt, wenn die volle Systemleistung nicht erbracht werden kann. Fail Safe bzw. Fail Stop sind weitere Methoden: Im Fehlerfall hält das System in einem sicheren Zustand an, statt den Betrieb weiterzuführen.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Ausklappen
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Ausklappen
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44790372 / Entwurf)