IT ganz ohne Ausfälle

Für Anwender ist es der Normalfall: "Ihre IT" steht immer und ohne Unterbrechung zur Verfügung. Für die IT-Mannschaft bedeutet dieser Anspruch zunächst einmal viel Arbeit - hochverfügbare Systeme können da helfen. [...]

Noch in den neunziger Jahren des letzten Jahrtausends war es durchaus nichts Ungewöhnliches für Anwender, wenn ihr Computer beziehungsweise der Dienst, den sie auf einem Computer für ihre Arbeit nutzten, einfach mal für eine Zeit nicht verfügbar war: „Der Computer geht mal wieder nicht!“ lautete damals eine gängige Phrase. In den heutigen Zeiten von „Always On“ und der allgewärtigen Vernetzung ist es fast undenkbar, dass ein Dienst oder gar ein kompletter Server nicht zur Verfügung stehen. So sind dann auch Systeme, die permanent und selbst im Falle eines Hard- oder Softwarefehlers ohne Unterbrechung zur Verfügung stehen, aus der Ecke der teuren Exotensysteme in den Bereich der normalen professionellen Server gewandert – sogenannte Hochverfügbarkeit ist überall anzutreffen.
Doch nicht alle Hersteller nehmen es mit den Definitionen so genau. Häufig wird dann ein System einfach mal als „hochverfügbar“ bezeichnet, eine USV macht den Server zum „absolut unterbrechungsfreien System“ und auch Begriffe wie „Disaster Recovery“ werden in diesem Zusammenhang immer wieder genannt. Dieser Artikel soll ein wenig Klarheit in das Begriffs-Wirrwarr bringen und einige Grundlagen der Hochverfügbarkeit von Server-Systemen erläutern.
WAS BEDEUTET DER BEGRIFF HOCHVERFÜGBARKEIT?
Wer sich im Web umschaut, findet eine ganze Reihe von Definitionen für den Begriff der Hochverfügbarkeit. Dabei beziehen sich die meisten Autoren auf eine grundlegende Definition des IEEE (Institut of Electrical and Electronics Engineers): Darin wird Hochverfügbarkeit als die Verfügbarkeit der IT-Ressourcen für den Fall bezeichnet, dass Systemkomponenten ausfallen. Oder etwas direkter ausgedrückt: Es bezeichnet ein System, dass trotz dem Ausfall einer seiner Komponenten den IT-Betrieb gewährleisten kann – und zwar mit einer ziemlich hohen Wahrscheinlichkeit. Laut Wikipedia-Definition stellt die Verfügbarkeit „die Wahrscheinlichkeit oder das Maß dar, dass das System bestimmte Anforderungen zu oder innerhalb eines bestimmten Zeitrahmens erfüllt“. Bei IT-Systemen wird diese Verfügbarkeit in Prozent angegeben. Gemessen wird dabei die Zeit, in der ein System läuft und alle Funktionen bereitstellt. Sie wird als „Uptime“ bezeichnet und immer ab dem letzten Systemstart berechnet.

Unternehmen wie Stratus, die sich auf hochverfügbare Systeme spezialisiert haben, gehen davon aus, dass Standard-Server („von der Stange“) auf Basis von Windows- oder Linux-Systemen heute bereits eine Verfügbarkeit von bis zu 99,9 Prozent erreichen können. Das entspricht dann einer Ausfallszeit von etwa 8,7 Stunden pro Jahr bei einem System das an 365 Tagen im Jahr in Betrieb ist. Das klingt zunächst einmal nicht nach besonders viel, aber für Anwendungen, deren Einsatz für ein Unternehmen entscheidend sind, ist auch eine solche Zeit nicht tolerierbar und bedeutet in der Praxis echte Verluste. So werden in der Regel auch erst Systeme, die eine Verfügbarkeit von 99,99 Prozent und mehr zu bieten haben, als hochverfügbare Systeme bezeichnet. Allerdings verzeichnen im praktischen Einsatz auch Systeme mit sehr vielen „Neunern“ hinter dem Komma durchaus Ausfallzeiten. 100 Prozent werden wohl Theorie bleiben, obwohl sogenannte „Always-On-“ oder fehlertolerante Lösungen heute durchaus mit Werten von 99,999 oder gar 99,9999 beworben und verkauft werden. Solche Systeme weisen dann eine Ausfallzeit von fünf bis hin zu nur einer Minute pro Jahr aus.
AEC: WIE VIEL HOCHVERFÜGBARKEIT BRAUCHT DER GESCHÄFTSBETRIEB?
Allerdings versteht es sich dabei fast von selbst, dass solche Systeme teuer sind. Die IT-Verantwortlichen und Administratoren in den Unternehmen stehen damit vor der Frage, wie hochverfügbar ihre Systeme wirklich sein müssen und welche Ausfallzeiten in der täglichen Praxis tolerierbar sind. Um diese Faktoren bewerten zu können, haben die Analysten der Harvard Research Group eine Einteilung geschaffen, die sie als Availibilty Environments (AE) bezeichnen. Sie unterteilen die „Verfügbarkeitsumgebungen“ in 5 Klassifizierungen und sprechen dabei dann auch von AEC: Availibility Environment Classifications. Eingeteilt wurden sie nach den Auswirkungen, die ein Ausfall der entsprechenden Dienste und Systeme auf den Geschäftsbetrieb und die Endnutzer hat:

• AE-0: Der Geschäftsbetrieb kann unterbrochen werden und die Verfügbarkeit der Daten ist nicht geschäftskritisch. Für die Endanwender bedeutet es, dass die Arbeit mit den Diensten/Systemen unterbrochen und angehalten werden kann und dass Daten bei einem Ausfall verloren gehen beziehungsweise korrumpiert werden können.

• AE-1: Hier geht es um Geschäftsfunktionen, die unterbrochen werden können, solange sichergestellt ist, dass das System die Verfügbarkeit der Daten garantiert. Aus der Sicht der Endanwender, wird es auch bei dieser Verfügbarkeitsklasse eine unvorhergesehene Unterbrechung der Arbeit und nicht zu kontrollierende Shutdowns gehen, aber die Integrität der Daten ist immer gewährleistet. Die Daten stehen dabei auf einem redundanten Speicher als Backup-Kopie zur Verfügung. Ein Dateisystem mit Journaling-Funktionen oder entsprechende Protokollfunktionen (log-based) sorgt dann im Zusammenhang mit diesem Backup dafür, unvollständige Transaktionen zu entdecken und die Daten wiederherzustellen.

• AE-2: Die Geschäftsfunktionen erlauben bei dieser Verfügbarkeit nur eine minimale Unterbrechung der Dienste. Dies darf zudem nur zu genau festgelegten Zeiten erfolgen. Die Anwender werden zwar eine kurze Unterbrechung erfahren, können sich aber gleich wieder anmelden. Allerdings kann es dabei in Einzelfällen notwendig sein, dass sie einige Transaktionen mit Hilfe der Protokolldateien neu ablaufen lassen müssen und dass sie eine Verschlechterung der Performance bemerken.

• AE-3: Bei dieser Klasse der Hochverfügbarkeit geht es um Geschäftsfunktionen, die ohne Unterbrechung ausgeführt werden müssen. Dies gilt entweder für genau festgelegte Zeiten oder für die meisten Stunden eines Tages sowie die meisten Tage einer Woche während des ganzen Jahres. Für den Anwender bedeutet es, dass er konstant ohne Unterbrechung arbeiten kann. Trotzdem kann es dabei vorkommen, dass eine Transaktion wiederholt werden muss, was der Nutzer aber nicht durch eine Unterbrechung des Betriebs, sondern höchstens durch Einbußen bei der Performance bemerkt.

• AE-4: Die Geschäftsfunktionen verlangen den kontinuierlichen Betrieb der IT und der Dienste. Eventuell auftretende Fehler müssen dabei für den Endanwender vollkommen transparent sein. Das bedeutet, dass die Nutzer keinerlei Unterbrechung ihrer Arbeit erfahren, und dass die Systeme einen 24×7-Betrieb gewährleisten.

Vielfach wird die Möglichkeit des Disaster Recovery als eine weitere Klasse aufgeführt, wobei allerdings grundsätzlich jeder dieser Verfügbarkeitsklassen um die entsprechenden Features für ein Disaster Recovery ausgestattet werden könnte. Deshalb ist es wichtig, eine Abgrenzung zwischen der reinen Hochverfügbarkeit und dem Disaster Recovery vorzunehmen. Wir gehen darauf in einem eigenen Artikel („So wird ihre IT fit für das Disaster Recovery“) genauer ein.
AUSPRÄGUNGEN, UMSETZUNGEN & LÖSUNGEN

Es gibt unterschiedliche Möglichkeiten, die Hochverfügbarkeit umzusetzen und dementsprechend auch unterschiedliche Ansätze, ein solches IT-System aufzusetzen. Wird eine hochverfügbare Lösung als Cold-Standby bezeichnet, so steht zwar bei Ausfall eines Systems oder einer Komponente für die Anwendungen ein entsprechender Ersatz bereit, auf den aber „per Hand“ umgeschaltet werden muss: Eine Ausfallzeit ist in diesem Fall also unvermeidbar. Kommt im Gegensatz dazu eine Lösung nach dem Hot-Standby-Prinzip zum Einsatz, so werden die Anwendungen beim Auftreten eines Fehlers oder Ausfalls automatisch auf dem Zweitsystem gestartet. Für ein solches Failover überwachen sich die beiden Server-Systeme in der Regel gegenseitig mittels eines sogenannten „Heartbeat“, damit der Wechsel sofort vollzogen werden kann. Generell sollen alle hochverfügbaren Systeme das Risiko ausschließen, dass ein Single-Point-of-Failure (SPOF) – also eine einzelne Komponente, die zum Ausfall eines ganzen Systems führen kann – auftreten kann. Hochverfügbare Cluster-Systeme (High-Availability Cluster oder Failover Cluster) besitzen redundante Systeme oder sogenannte Knoten (nodes), die einen Dienst übernehmen können, wenn ein Fehler auftritt. Grundsätzlich gelten Cluster-Lösungen als aufwändig, da sie doch einen nicht unerheblichen Aufwand bei Implementierung und Administration erfordern.

Windows-Server stellen den Administratoren bereits seit der Version Windows Server 2000 eine Failover-Cluster-Lösung zur Verfügung, aber erst mit der Version Windows Server 2008 wurden Konfiguration und Einsatz dieser Technik von Microsoft so gestaltet, dass ein solcher Cluster auch von Administratoren aufgesetzt werden kann, die sich nicht auf diesen Bereich der IT-Technik spezialisiert haben. Diese positive Trend setzte sich mit den aktuellen Versionen Windows Server 2012 und 2012R2 weiter fort, da dort Einrichtung und Betrieb eines Failover-Clusters durch den neuen Server Manager noch weiter übersichtlicher gestaltet wurden und durch die Bereitstellung von „Best Practices“-Tipps unterstützt werden.

Anbieter wie Vision Solutions mit ihrer Software-Lösung Double-Take und Stratus mit Hardware-Lösungen wie die fehlertoleranten ftServer-Systeme oder Software-Lösungen wie everRun stellen Systeme bereit, die entsprechend einfacher zu konfigurieren und einzusetzen sein sollen. Dabei verhalten sich beispielsweise fehlertolerante Server, die aus komplett redundanten Komponenten aufgebaut sind, aus der Sicht der Benutzer im täglichen Betrieb wie ganz normale Server. Dadurch ist dann auch die Administration nicht aufwändiger oder schwieriger als bei Standard-Server.

Rein auf Software basierende Lösungen wie „Double-Take Availability für Windows“ des Herstellers Vision Solutions, das aktuell in der Version 7.0 zur Verfügung steht, bieten sie hier als relativ kostengünstige und einfachere Alternative zu den Cluster-Systemen an. Das Prinzip dieser Software: Sie arbeitet mit einer laufenden Replikation der Daten von produktiven Windows-Servern auf „Replikate“. Bei diesen Replikaten handelt es sich dann typischerweise um virtuelle Maschinen. Diese VMs werden durch die Software entweder in einer VMware ESX- oder einer Microsoft Hyper-V-Umgebung automatisch eingerichtet. Wer dabei auf sein Budget achten muss, kann von Microsofts Lizenzpolitik profitieren und die auf den Windows Servern zur Verfügung stehende kostenlose Virtualisierungs-Software Hyper-V zusammen mit der Software einsetzen.

Während bei anderen Ansätzen ein ausgefallener Server aus den Backups in Stunden wieder einsatzfähig gemacht wird, startet diese Lösung im Fehlerfall ein Replikat als virtuelle Maschine. Der Administrator kann einstellen, wie lang das Programm die Nichterreichbarkeit des Quellservers toleriert, ehe es das Replikat startet. Beim Einsatz einer solchen Lösung ist es zudem nicht entscheidend, ob es sich bei dem Quellserver um eine Windows-Installation auf einem physikalischen Server handelt oder um eine virtualisierte Maschine – sie werden genau gleich behandelt.
DISASTER-RECOVERY – ANDERER EINSATZ, ANDERE ZIELE
Vielfach werden Disaster Recovery und Hochverfügbarkeit noch synonym verwendet. Hochverfügbare Systeme und/oder ihre Komponenten werden in diesem Zusammenhang auch als „Fehlertolerant“ bezeichnet oder Hersteller werden mit der Fähigkeit ihrer Lösung, im Fehlerfall ein sogenanntes „fail over“ durchzuführen und so den Betrieb zu garantieren. Hochverfügbarkeit kann natürlich auch auf Ebene der einzelnen Komponenten erreicht werden und steht mit durchaus im Einklang mit den anfangs erwähnten unterschiedlichen Definitionen dieses Begriffs. Wenn beispielsweise die Maschinen in einem Rechenzentrum mit einer doppelten unterbrechungsfreien Stromversorgung (USV) ausgestattet wird, so gehen viele IT-Verantwortliche dann davon aus, dass diese Rechner auch eine entsprechendes „Disaster“ gut überstehen könnten.
Eine derartige Konstellation ist aber keinesfalls als ein „Disaster Recovery“ zu bezeichnen. Damit eine Installation für ein Disaster Recovery fit ist, sollte sie die folgenden Merkmale aufweisen, die so in ihrer Gesamtheit für ein hochverfügbares System nicht notwendigerweise vorhanden sein müssen:

• Ein Disaster Recovery beinhaltet immer den Einsatz eines alternativen Standorts, so dass die Redundanz nicht nur auf der Ebene der Systeme oder des Rechenzentrums gewährleistet ist.

• Ein reines Fail-Over reicht bei Disaster Recovery nicht aus – hier muss müssen die Dienste nach einem Vorfall (beispielsweise Feuer, Überschwemmung, Erdbeben) vollständig und ohne Datenverlust wiederhergestellt werden können.

• Während die Hochverfügbar in der Regel dazu dient, bei einem vorhersehbaren Fehler wie etwa dem Ausfall eines Prozessors, eines Speichermoduls oder einer Stromversorgung den Betrieb zu garantieren, deckt eine Disaster-Recover-Lösung auch multiple Fehler im Rechenzentrum ab.

• Eine Lösung für die Hochverfügbarkeit ist grundsätzlich auf die Implementierung und das Design der System ausgerüstet – es handelt sich also um eine „rein technische“ Lösung. Eine umfassende Lösung zum Disaster Recovery muss zudem die notwendigen Prozesse und damit auch die Mitarbeiter mit einbeziehen, die notwendig sind, um die Dienste und Systeme komplett wiederherzustellen.

Eine Lösung für das Disaster Recovery kann selbstverständlich auch die Techniken für Hochverfügbarkeit beinhalten. Ein beispielhafter Ansatz dafür wäre der Einsatz von hochverfügbaren Server-Systemen in einem Cluster im produktiven Rechenzentrum für eine spezifische Anwendung, während die Backup-Hardware in einem anderen Recovery-Rechenzentrum installiert ist. Die Daten von den produktiven Server-Systemen werden dann in das Recovery-Rechenzentrum gesichert oder repliziert, wobei in die Systeme in beiden Rechenzentren vor dem Ausfall von Komponenten geschützt sind. Fällt das produktive Rechenzentrum beispielsweise durch ein Feuer aus, so können die Daten durch das Recovery-Rechenzentrum wiederhergestellt werden.
*Thomas Bär und Frank-Michael Schlede sind freie Journalisten.