Die nachfolgende Fallstudie zur Systemverfügbarkeit und Ausfallsicherheit betrifft ein mittelständisches Dienstleistungs- und Logistikunternehmen in der Schweiz. Die dortigen IT-Verantwortlichen überlegten zum Zeitpunkt der Studie einen Windows-Cluster anzuschaffen, da die Kosten der Nicht-Verfügbarkeit von zentralen Serverdiensten relativ hoch waren, während auf der anderen Seite die Verfügbarkeit des transObjects®-Servers dank der Failover-Vorrichtung deutlich spürbar in ganz anderen Bereichen angesiedelt war.
Die K&S Informatik GmbH wurde beauftragt, eine Kosten/Nutzen-Rechnung im Hinblick auf die eventuell anzuschaffende Cluster-Vorrichtung zu erstellen und diese vor den Hintergrund der empirischen Erfahrungen mit der transObjects® Failover-Vorrichtung zu stellen. Dies war nur mit einem stochastischen Ansatz zu machen, den wir nachfolgend präsentieren.
1. Stochastische ➡ Natur der Systemverfügbarkeit
______________
➡ Stochastik [griech.], Bezeichnung für mathematische Verfahren zur Untersuchung zufallsabhängiger Ereignisse, sei es aufgrund von der Natur des zu untersuchenden Systems, sei es aufgrund von statistischen Erkenntnissen (z. B. von Stichproben).
.
Im Zusammenhang mit der Verfügbarkeit eines Systems bzw. dessen zentraler Komponente (im Folgenden „Backbone“) wird meistens mit einer dimensionslosen Zahl operiert. Doch was bedeutet beispielsweise eine Systemverfügbarkeit von 0.99 (99%)?
Betrachten wir zunächst ein Backbone an einem Serverstandort und lassen dies im Wesentlichen aus genau einem Server bestehen. Vereinfachen wir ferner unsere Überlegungen, indem wir einen planmäßigen Ausfall des Backbones (etwa aufgrund von Wartungsarbeiten) völlig außer Betracht lassen. Unter einem „Totalausfall“ verstehen wir ein Versagen des Backbones, was die Inanspruchnahme von Serverdiensten in einem bestimmten Zeitintervall gänzlich unumgänglich macht. Im Folgenden betrachten wir nur die Totalausfälle. Dies bedeutet keine wesentliche Einschränkung der Allgemeinheit, da wir jeden Teilausfall auf einen Totalausfall mit entsprechend geminderten Folgen zurückführen können.
Falls uns Erfahrungswerte eines hinreichend langen Betriebszeitintervalls vorliegen, sind wir schnell geneigt, eine hieraus abgeleitete Aussage über die Verfügbarkeit eines Systems bzw. dessen Backbones zu formulieren. Man braucht nur noch die Ausfallzeiten der empirisch festgehaltenen (Total-) Ausfälle aufzuaddieren und diese ins Verhältnis zu der gesamten Laufzeit zu setzen. Für mathematische Puristen, die wir vorliegend ebenfalls zufrieden stellen wollen, hieße es:
Diese Zahl ist genau genommen die Nicht-Verfügbarkeit. Die Verfügbarkeit selbst wäre dann das 1-η.
Dabei können die Ursachen für jedes Ausfallereignis ω von sehr unterschiedlicher Natur sein – vom „klassischen“ Hardwareversagen über ein Software- bzw. Konfigurationsfehler oder gar ein organisatorisches Problem, bis hin zu einem destruktiven Eingriff und höherer Gewalt. Und genau an diese sozusagen naturgemäße Komplexität der Wechselwirkung rund um die Verfügbarkeit eines hoch technisierten Systems verdeutlicht deren eigentliche stochastische Natur; dazu später mehr.
Wir sehen an dieser Stelle überaus deutlich, dass diese Wechselwirkung all der Systemparameter von der empirisch ermittelten Verfügbarkeit allenfalls nur sehr indirekt erfasst wird. Sie besagt nichts über die tatsächlich lauernden Gefahren, sei es aufgrund des informationstechnischen Grundkonstruktes, sei es aufgrund von organisatorischen Belangen rund um das betr. System und sie trifft eine reine a posteriori Aussage. Folglich benötigen wir ein anderes Werkzeug, um die eigentliche Frage der vorliegenden Studie zu beantworten, nämlich die, wie sich ein Servercluster auf die Verfügbarkeit unseres Systems auswirken würde.
2. Stochastisches Zeit-Diskontinuum
Betrachten wir ein Ereignis ω, das zum Totalausfall unseres Backbones führt. Sei dieses Ereignis beispielsweise ein Ausfall eines RAM-Chips im Server. Setzen wir voraus, dass ein solcher Ausfall zum Anhalten des Servers führt, obwohl nicht unwahrscheinlich ist, dass das interne Hardwaremanagement einen solchen Ausfall erkennen und mittels „Isolierung“ umgehen könnte.
Wir wissen, dass Silizium-Komponenten heutzutage mit mehreren Megahertz takten und mit jedem „Takt“, was ja einen Schaltvorgang im Inneren des Chips bedeutet, immer wieder aufs Neue Gefahr laufen, Schaden zu nehmen. Wir spüren irgendwie, dass diese aufeinander folgenden Schaltvorgänge die eigentlich kritischen Momente für unseren RAM-Chip sind. Daher sehen wir die Zeiträume zwischen den einzelnen Takten als irrelevant an, da sie keine Gefahr für eine Silizium-Komponente darstellen. Wir untersuchen demnach die Lebensdauer des RAM-Chips nicht in einem klassischen Zeitkontinuum, sondern vielmehr in einem (zeitlichen) Diskontinuum.
Sei ε die Wahrscheinlichkeit für einen Ausfall des RAM-Chips bei einem beliebigen Schaltvorgang (Takt). Diese Wahrscheinlichkeit – normalerweise eine verschwindend geringe Zahl – ist wohl im Wesentlichen von der Materialbeschaffenheit und der Betriebsumgebung abhängig. Wir lassen eine zeitliche Veränderung dieser Parameter (etwa infolge von Alterungsprozessen) außer Betracht. Ähnlich wie im russischen Roulett bedeutet jeder Takt ein neues „Abdrücken“, mit der Gefahr ε, dass ein scharfer Schuss losgeht. Die Wahrscheinlichkeit, dass dies in den ersten n Versuchen erfolgt, ist eine exklusive Alternative von einzelnen Ereignissen, was für unsere mathematischen Puristen folgendermaßen aussieht:
Es entspricht durchaus der Lebenserfahrung, dass es im Laufe der Zeit immer wahrscheinlicher wird, den Ausfall unseres Chips zu erleben. Mit anderen Worten, irgendwann einmal geht ein scharfer Schuss los, wenn man das russische Roulett oft genug bemüht: die obige Wahrscheinlichkeit geht gegen 1 bei wachsendem n.
Sicherlich können wir in unserem zeitlichen Diskontinuum von der Taktung abstrahieren und unsere obigen Überlegungen auf die Betriebszeit einer Komponente verallgemeinern. Seien:
die Ausfallwahrscheinlichkeit aufgrund vom Ereignis ω im Zeitraum T (1 Jahr);
die durchschnittliche Dauer des Ausfalls aufgrund vom Ereignis ω;
Wären uns diese Größen für alle Ausfallereignisse bekannt, so würden wir sofort den stochastischen Erwartungswert der jährlichen Ausfallzeit bilden und diesen ins Verhältnis zu der jährlichen Betriebsdauer setzen können. Damit hätten wir die stochastische Nicht-Verfügbarkeit unseres Systems:
Natürlich ist es ein absolut aussichtsloses Unterfangen, all die verfügbarkeitsrelevanten Ereignisse zu erfassen und entsprechend obiger Formel zu quantifizieren. Aber immerhin leiten wir daraus eine längst verinnerlichte Weisheit, nämlich die, dass wir die Verfügbarkeit unseres Backbones dadurch erhöhen können, indem wir einfach die jeweiligen Summanden möglichst verkleinern – oder anders ausgedrückt, indem wir die jeweiligen Ereignisse unwahrscheinlicher machen und/oder deren Folgen (Ausfallzeiten) minimieren. Das führt zu einer Reihe von bekannten Maßnahmen, die bis ins Organisatorische hinein reichen würden, weshalb auf deren Auflistung hier verzichtet werden soll. Aus unserer Formel folgern wir, dass wir damit ohnehin ein eher mäßiges Resultat erzielen würden. Im kommenden Kapitel versuchen wir einen Ansatz, der uns signifikant weiterbringt.
3. Verfügbarkeit eines Backbones
Die Aussichtslosigkeit der exakten Erfassung aller Ausfallereignisse zwingt uns dazu, eine Systemverfügbarkeit aufgrund von Erfahrungswerten mit ähnlichen Systemen bzw. aufgrund von Normungen, anzunehmen. Dies ist keineswegs der Rückfall in die empirische Verfügbarkeit aus dem Kapitel 1. Im Gegenteil. Der statistische Ansatz ist ein probates und anerkanntes Mittel der Stochastik.
Betrachten wir einen realen Fall des eingangs erwähnten mittelständischen Unternehmens aus Zürich. Für systemkritische Dienste (etwa MS Exchange, MS IIS etc.) wurde zunächst eine neue Hardware ohne Cluster angeschafft und in Betrieb genommen. Im Zeitraum unmittelbar danach konnte zunächst ein überaus erfreulicher 3000-stündiger Betrieb des Servers ohne einen außerplanmäßigen Unterbruch verzeichnet werden. Auch der daraufhin erfolgte ca. 30-minütige Ausfall aufgrund des Deadlocks tangierte nur ganz wenig die insgesamt sehr hohe empirische Verfügbarkeit.
Allerdings, bei näherem Hinsehen war da noch zwischendurch ein durch höhere Gewalt verursachter Ausfall der Internetverbindung, was zu einem gewissen Prozentsatz als Ausfallzeit zu zählen war, und die eine oder andere Kleinigkeit auch noch – und sei dies nur eine vorübergehende Software-Fehlfunktion. Ferner ist nicht zu vergessen, dass im Laufe der Zeit mit fortschreitenden Alterungsprozessen zu rechnen ist und dass einige Ereignisse, obwohl diese im vorliegenden Falle nicht eingetreten waren, immer noch mit einer gewissen Wahrscheinlichkeit über allen wie das sprichwörtliche Damoklesschwert schwebten. Daher war man im vorliegenden Falle, bei einer groben Orientierung an den Industrienormen bzw. sonstigen Erfahrungswerten, mit einer Nicht-Verfügbarkeit von:
recht gut bedient. Das klang zunächst einmal nicht so schlecht, bedeutete aber einen stochastischen Erwartungswert von immerhin knapp einem ganzen Kalendertag Ausfallzeit pro Jahr:
Ein totaler und nicht planmäßiger Ausfall eines systemkritischen Backbones ist sicherlich stets mit mehr oder minder gravierenden Kosten verbunden. Diese Kosten wurden vorliegend mit 500,- CHF pro Stunde angesetzt, was zu einem stochastischen Erwartungswert der jährlichen Verluste bedingt durch Ausfälle des betreffenden Servers von knapp 11’000 CHF pro Jahr geführt hätte.
Vor dem Hintergrund obiger Zahlen wurde die K&S GmbH beauftragt, die entsprechenden Erwartungswerte erstens für den transObjects®-Server zu ermitteln, der ja zum Zeitpunkt der Studie bereits unter Shadow-Failover lief (hierzu später mehr) und zweitens zu errechnen, inwieweit eine Failover-Vorrichtung die stochastische Verfügbarkeit des betreffenden Servers verändern würde.
4. Grundzüge des Clusterprinzips
Die Grundidee des Failover, d.h. der Steigerung von Serververfügbarkeit mittels einer wie auch immer gearteten Serverredundanz, ist denkbar einfach. Will man beispielsweise eine simple Serverfreigabe ?ber den Ausfall des Servers hinaus verf?gbar machen, so sorgt man wohl dafür, dass diese Freigabe notfalls von einem anderen Server „serviert“ werden kann, wenn denn der Hauptserver hierzu vorübergehend nicht in der Lage sein sollte.
Technisch gesehen würde man dies wohl so zu bewerkstelligen suchen, indem man eine Art „Shared Drive“ gleichzeitig mit zwei oder mehr Servern (sog. Cluster-Nodes) verbinden würde. Dabei würde man beide Nodes ans gleiche LAN bringen, jedoch nur einen der beiden zu dem „primären“ erklären, der seine Serveraufgaben (z.B. simple Freigaben) wahrzunehmen hätte. Sollte dieser aus irgendwelchen Gründen ausfallen, so würde man den zweiten der beiden vorübergehend zu dem primären erklären und ihn aufgrund seiner Verbindung zu dem Shared-Drive, wo sich die betreffenden Freigaben befinden, aktivieren.
Es stellt sich nur noch die Frage, inwieweit sich so etwas irgendwie automatisch machen ließe, d.h. ob es nicht irgendwie möglich wäre, dieses „Failover“ einem speziellen Dienst zu überlassen, der den Ausfall des primären Nodes selber erkennt, den sekundären Node entsprechend aktiviert und den Clients den Zugriff unter unveränderten Eckdaten gewährt. Bei Microsoft ist dieser Dienst der sog. Clusterdienst. Die Clustertopologie sieht, anhand des vorliegend relevanten Exchange-Clusters, folgendermaßen aus:
5. Serververfügbarkeit unter einem Servercluster
Bevor wir uns an das Thema Verfügbarkeit eines Clusters heranwagen, machen wir den folgenden Ansatz:
Es ist klar, dass die hier angesetzten Zahlen existieren (Zwischenwertsatz) und dass es sogar unendlich viele Zahlenpaare gibt, die der obigen Gleichung genügen. Doch wie sind denn pT und t zu interpretieren?
Rufen wir noch einmal kurz das russische Roulett aus dem Kapitel 3 in Erinnerung. Dort ging es um einen einzelnen RAM-Chip. Doch k?nnen wir nicht eine ähnliche Natur dem gesamten Backbone unterstellen? Beide Zahlen sind dann eine Art Durchschnittsgrößen, die zum gleichen Resultat führen. Das einzige Ausfallereignis lautet dann „Ausfall des Backbones“ bzw. des Clusternodes.
Setzen wir eine Gleichwertigkeit der beiden Clusternodes voraus, so ist die Ausfallwahrscheinlichkeit des Clusters aus der mathematischen Konjunktion der Ereignisse „Ausfall des Nodes 1“ und „Ausfall des Nodes 2 bevor Node 1 wiederhergestellt werden konnte“:
Das hat für die Nicht-Verfügbarkeit eine fast sensationelle Konsequenz:
Es spielt demnach eine untergeordnete Rolle, wie wir unsere Durchschnittswerte ansetzen, denn in jedem Falle ziehen wir sehr kleine Zahlen ins Quadrat, was eine dramatische Schrumpfung der Nicht-Verfügbarkeit nach sich ziehen würde. Versuchen wir es bloß mit unserer zuvor genannten Zahl, so ergäbe sich daraus anstatt 0.25% gerade mal 0.000625% und anstatt knapp 11’000,- CHF gerade mal knapp 30,- CHF!
Sicherlich haben wir hier ein idealisiertes Bild des Failover-Clusters gezeichnet. Denn zum einen sind nicht alle Dienste Cluster-fähig und zum anderen sind beide Nodes nicht desimilar redundant (bedeutet soviel, wie nach unterschiedlichen technischen Prinzipien ausgelegt). Dennoch konnte eine Ersparnis von mehreren Tausend Stutz pro Jahr konnte guten Gewissens angenommen werden. Und was noch viel wichtiger war: ein ähnlicher Kosteneffekt konnte dem hochverfügbaren transObjects®-Server bescheinigt werden und das bereits ohne einen kostspieligen Servercluster!