Wir unterstützen...

Elterninitiative Kinderkrebsklinik e.V

Kinderkrebsklinik e.V

Sponsoren

Wir danken unseren Sponsoren:

Permanente Sponsoren

Uni Düsseldorf
(Raum und Beamer)


(Preise)


(Preise)


(Preise)


(Preise)

Mitgliedschaften



java.net Member

Events

Nachlese: Unkaputtbar - Muster für Resilient Software | Print |
Written by Philip Höfges   
Friday, 12 June 2015 14:12

>> Video

Es ist schönes Frühsommerwetter. Was unternimmt man am Besten? Klar, den Rheinjug-Vortrag von Uwe Friedrichsen besuchen. Das dachten sich auch die etwa 75 Zuhörer, die sich dafür interessiert haben, was Uwe zum Thema Resilent Software Design zu erzählen hat. Uwe Friedrichsen ist Mitarbeiter bei codecendric und hat seinen Schwerpunkt auf verteilte Systeme gelegt.

Zunächst fragt Uwe, wie lange es das Publikum wohl aushalten würde. Die vollen 90 Minuten, so das Meinungsbild. Und damit legt Uwe los. Am Anfang des Vortrags wird geklärt, was Resilence überhaupt ist. Im Bereich der Softwareentwicklung bedeutet dies, das Systeme sich in Produktion befinden und verfügbar sein sollen. Aber wie definiert man dann Verfügbarkeit? Für den Redner gibt es zwei wesentliche Werte, die dies ausdrücken: Mean Time to Failure (MTTF) und Mean Time to Recovery (MTTR). Mit der Formel MTTF / (MTTF + MTTR) kann man Verfügbarkeit gut angeben. Wie erreicht man nun sein Ziel möglichst hoher Verfügbarkeit? Im ersten Ansatz wird versucht, die durchschnittliche Zeit, in der das System fehlerfrei läuft (MTTF) zu maximieren. Dazu wird noch angemerkt, dass nahezu jedes System ein verteiltes System ist. Es existieren oftmals andere Systeme, von denen der Benutzer keine Kenntnis hat. Dies kann zu Fehlern führen. Fehler sind heutzutage leider keine Seltenheit mehr, sondern gehören dazu. Uwe fasst dies sehr schön in einem Mantra zusammen: „Versuche nicht, Fehler zu vermeiden, sondern akzeptiere deren Existenz.“. Das bedeutet, man kann auf Fehler nicht unbedingt einwirken, was den Ansatz, die MTTF zu maximieren sehr schwierig macht. Der andere Ansatz liegt in der Minimierung der MTTR, als möglichst wenig Zeit verstreichen zu lassen für die Wiederherstellung des Systems. Dazu gibt es zwei Möglichkeiten: Im besten Fall, bekommt der Benutzer gar nicht mit, dass es einen Fehler gegeben hat, da er so schnell repariert worden ist. Im schlechten Fall ist diese Zeit zu kurz, so dass der Benutzer den Fehler zwar erkennt, ihm jedoch eine Teilmenge des Systems zur Verfügung gestellt wird, damit er erkennt, dass nicht alles fehlerhaft ist. Damit hat Uwe die Grundlagen des Themas abgearbeitet.

Im zweiten Teil des Vortrags gibt Uwe eine Mustersprache an, anhand derer man sehen wird, wie Resilient Software in der Realität ungefähr aussieht. Er spricht dabei sehr viele Unterpunkte an.

Einer der Wichtigsten ist die Isolation. Es darf niemals soweit kommen, dass das gesamte System ausfällt. Dazu wird das Gesamtsystem aufgeteilt und kleine Untersysteme. Sollte eines von diesen ausfallen, läuft das Gesamtsystem jedoch weiter, weil die Untersystem unabhängig voneinander agieren können. Ebenfalls wichtig ist die Vermeidung von kaskadierenden Abbrüchen. Als wenn an Punkt A etwas schief geht, geht auch an Punkt B etwas schief usw. Dazu gibt es die sogenannten „Bulkheads“, zu deutsch Abschottungen. Die einzelnen Teilsysteme sollen möglichst disjunkt voneinander arbeiten. Und es sollte besser klappen als bei den Flutungsrräumen der Titanic, da diese nur im unteren Bereich angebracht worden sind. Diese kleine Anekdote sorgt für Heiterkeit im Publikum. Zuletzt möchte ich noch den Punkt der Relaxed Temporal Contraints erwähnen. Jeder Rechner mag vielleicht eine hohe Einzelverfügbarkeit haben, jedoch sinkt die Gesamtverfügbarkeit des System mit jedem Rechner im System ab. Dies bedeutet, dass die Konsistenz eines Systems nicht immer sofort geregelt werden muss, also alle System gleichzeitig online sind, sondern dass dies nach und nach geschehen sollte. Als Beispiel nennt Uwe eine Überweisung bei einer Bank. Das Geld ist vom eigenen Konto schneller verschwunden, als man „Überweisung“ sagen kann. Dies bedeutet aber definitiv nicht, dass es auch genau so schnell auf dem Konto des Empfängers liegt. Dies kann Tage dauern. Aber davon bekommt der Benutzer unmittelbar nichts mit. Das ACID Prinzip gilt heutzutage nicht mehr.

Zum Abschluss liefert Uwe Friedrichsen eine Zusammenfassung des Vortrags in drei Stichpunkten:

  • Systeme sind verteilt und es wird noch schlimmer
  • Fehler sind normal
  • Resilence ist notwendig

Mit diesen Worten beendet Uwe den Vortrag. Anschließend wird wie immer heiß über das Thema diskutiert, was aber vielleicht auch am Wetter liegt.