Datensicherung: Hochverfügbarkeit im Kosten-Nutzen-Dreieck:
Praxis: Was beim Einrichten einer hoch verfügbaren IT-Infrastruktur zu beachten ist

von Bernd Reder (bernd.reder@networkcomputing.de), Joachim Brebeck (Doubletake Software)

Share
30.03.2009

Gerade in Krisenzeiten fällt die Investition in nicht unmittelbar produktive Technik besonders schwer. Aber ein Ausfall eines geschäftskritischen Servers ist deutlich teurer als ein tragfähiges Disaster-Recovery-Konzept. Doch welcher Server braucht wie viel Hochverfügbarkeit? Für ein optimales Preis-Leistungs-Verhältnis empfehlen Experten eine Strukturierung nach der Sicherheits- und Failover-Pyramide.

Die Abwrack-Prämie macht’s möglich: Jahreswagen gehen weg wie warme Semmeln. Der Kunde steht mit gezücktem Scheckbuch im Verkaufsraum. Doch dann muss der Verkäufer zerknirscht einräumen, dass der Wagen zweimal verkauft wurde. »Wir hatten gestern keine Verbindung zur zentralen Datenbank«, entschuldigt er sich.

Ein solcher Ausfall kann richtig teuer werden. Im günstigsten Fall ist das Geschäft perdu – und der Kunde gründlich verärgert. Wer aber ein Auto doppelt verkauft, oder eine Wohnung doppelt vermietet, muss unter Umständen auch für den entstandenen Schaden haften.

Die Anforderungen in puncto Hochverfügbarkeit lassen sich mithilfe der Sicherheits- und Failover-Pyramide ermitteln.

Wie jede Technik kann auch ein einmal Server kaputt gehen. Verständnis für eine längere Downtime darf ein Anbieter von Online-Services allerdings nicht erwarten. Kunden wollen rund um die Uhr nach Gebrauchtwagen oder freien Wohnungen suchen, Informationen abrufen oder online einkaufen.

Kaum jemand wartet mehr als eine Viertelstunde, bis eine ausgefallene Web-Site wieder im Netz ist. Wozu auch: Die Konkurrenz ist ja nur wenige Mausklicks entfernt.

Hochverfügbarkeit in der Kosten-Nutzen-Analyse

Egal, ob beim Online-Shop, einer Bestelldatenbank oder in Produktion und Vertrieb: Von der Verfügbarkeit unternehmenskritischer Server hängt alles ab. Ein startbereites Backup-System muss immer vorhanden sein, und das möglichst an einem räumlich getrennten Standort. Sonst wird ein Brand oder Wasserschaden im Rechenzentrum zur hausgemachten Unternehmenskrise.

Dass Business Continuity und Disaster Recovery wichtig sind, wird wohl niemand mehr ernsthaft in Zweifel ziehen. Strittig bleibt allerdings die Verhältnismäßigkeit. Beileibe nicht jeder Server verlangt automatisches Failover oder permanente Replikation, auch bei den Applikationen.

Wer auf Nummer sicher gehen, aber nicht mit Kanonen auf Spatzen schießen will, sollte seine Server daher in Prioritätsklassen aufteilen. Auf der Basis dieser Eingruppierung lässt sich ein sinnvoller und damit auch kostengünstiger Recovery-Plan aufstellen.

Die Spitze des Sicherheits-Eisbergs

Die absolute Spitze der Sicherheitspyramide bilden Server, die buchstäblich keine Sekunde ausfallen dürfen, zum Beispiel im Banken- oder Börsenverkehr. Die Zeit zwischen Ausfall des Primär- und dem Start den Sekundärsystems, die so genannte RTO (Recovery Time Objective), muss praktisch bei Null liegen. Hier darf kein einziges Byte verloren gehen.

Primär- und Sekundär-System müssen immer exakt auf demselben Stand sein. Das Zurückschreiben eines auch nur 15 Minuten alten Backups ist nicht tolerierbar, auch die RPO (Recovery Point Objective) geht somit gegen Null.

Dies ist die Welt der SANs (Storage Area Networks), der synchronen Replikation, der Fibre-Channel-Verbindungen und der hoch redundanten Systeme. Hier ist die leistungsfähigste (und damit teuerste) Hard- und Software gerade gut genug.

Einsparpotenziale lassen sich an der obersten Spitze kaum ausmachen. Daher wird dieser Bereich hier weniger ausführlich behandelt.

Synchrone Replikation

Was die High-End-Lösungen so teuer macht, ist unter anderem die synchrone Replikation. Dabei fängt die Software Schreibzugriffe ab und sendet sie gleichzeitig an das primäre und sekundäre Storage-Array. Erst wenn beide den Empfang bestätigt haben, akzeptiert das Programm den nächsten Write-Request.

Beide Speicher haben also immer exakt denselben Stand, Datenverluste sind praktisch ausgeschlossen. Synchrone Replikation lässt allerdings den Datenverkehr im Netz stark ansteigen und erfordert daher oft schnelle und teure Fibre-Channel-Verbindungen, die nur bis zu einer Entfernung von etwa 16 Kilometern sinnvoll eingesetzt werden können.

Die synchrone Replikation eignet sich daher eher für lokale Backups – und für ausgesprochen üppige Budgets.

Asynchrone Replikation

Akzeptiert man allerdings ein Recovery Point Objective im Bereich weniger Minuten, ergeben sich bereits enorme Einsparpotenziale. Dann kann der Anwender nämlich auf asynchrone Replikation zurückgreifen.

Dabei werden Write-Requests des Betriebssystems zunächst an das lokale Array weitergereicht und erst nach dem Schreibvorgang auf das sekundäre, entfernte Array kopiert. Dabei wartet die Anwendung nicht auf Bestätigungen, sondern fährt unmittelbar mit den nächsten Daten fort.

Die Auswirkungen auf die Performance sind dabei minimal. Daher kann asynchrone Replikation effektiv und wirtschaftlich auch über vergleichsweise langsame WAN-Verbindungen betrieben werden.

Wichtige Daten sollten auf Server und Storage-Systeme repliziert werden, die sich an einem anderen Firmenstandort oder in einem Rechenzentrum eines Service-Providers befinden.

Asynchrone Replikation ist natürlich nicht ganz verlustfrei wie die synchrone Variante. Für die meisten Unternehmen und Einsatzbereiche ist sie allerdings völlig ausreichend und bietet das beste Preis-Leistungs-Verhältnis. Aber auch in der Welt der asynchronen Replikation gibt es Unterschiede. Daher ist eine weitere Strukturierung sinnvoll.

Unmittelbar geschäftskritische Server

Die Bestelldatenbank für die Autoverkäufer muss nach einer Viertelstunde wieder online sein, auch nach einem Brand im Rechenzentrum. Gleiches gilt für einen Online-Shop.

Solche unmittelbar geschäftskritischen Server stehen im Bereich asynchrone Replikation ganz oben in der Sicherheitspyramide. Hier muss ein mit dem Produktionssystem weitgehend identischer Backup-Server im Stand-by auf schlechtere Zeiten warten. Das Recovery muss automatisch erfolgen und alle Applikationen auf dem neuesten Stand wieder herstellen.

Dann merken die Kundenbetreuer kaum etwas von der Beinahe-Katastrophe. Alle Benutzeroberflächen und Daten sehen aus wie immer.

Hier braucht man ein asynchrones Replikationsprogramm mit Full-Server-Failover. Es repliziert permanent nicht nur die Daten, sondern auch alle Änderungen an den Anwendungen, zum Beispiel Service Packs oder Updates.

Der manuelle Wartungsaufwand ist gering: Der Backup-Server übernimmt vollautomatisch den Posten seines ausgefallenen Kollegen. Und für den Anwender sieht nach wenigen Minuten alles wieder aus wie immer.

Das ist technisch aufwändig, daher nicht gerade billig und nur für die oberste Stufe der asynchronen Sicherheitshierarchie zu empfehlen – dort allerdings mit Nachdruck. Auch in Krisenzeiten muss der Controller einsehen, dass Vorsorgen in diesem Fall günstiger ist, als Umsatz und Kunden durch Offline-Zeit zu verlieren.

Mittelbar geschäftskritische Server

Bei der Ersatzteil-Datenbank kann man schon wieder ein wenig mehr den Rotstift ansetzen. Sie ist über verschiedene Standorte verteilt; an den Applikationen wird kaum etwas geändert.

Längere Ausfallzeiten sind aber auch auf dieser Sicherheitsebene kostspielig. Deshalb sollte auch hier ein automatisches Failover möglich sein. Es müssen aber nur die Daten repliziert werden.

Dann kann sich das Controlling bereits über Einsparungen freuen. Die Software wird preisgünstiger, vor allem aber die Backup-Hardware. Mehrere Server können nämlich mit zeitgemäßen Programmen auf ein und dasselbe Backup-System oder auf virtuelle Server repliziert werden.

Auch in diesem Fall ist nach einer Viertelstunde jedes Desaster vergessen. Sicherheits-Puristen mögen einwenden, dass dieses Konzept bei Mehrfach-Ausfällen nicht mehr greift. Diese sind aber recht unwahrscheinlich. Daher ist eine Many-to-one-Datenreplikation mit automatischem Failover durchaus der richtige Kompromiss.

Sekundär-Server sichern

Eindeutig übers Ziel hinaus schießt, wer zum Beispiel das Archiv für Texte und Mails mit einem automatischen Failover-System absichert. Bei diesen so genannten Sekundär-Servern ist ein Ausfall von ein paar Stunden keine Tragödie.

Ganz ohne Absicherung geht es aber auch auf dieser Stufe der Sicherheitspyramide nicht. Hier kann man aber getrost zu einem preiswerten Software-Paket greifen. Es repliziert permanent alle Änderungen im Datenbestand. Wieder ist Many-to-one-Replikation möglich, was das IT-Budget weiter schont. Das Recovery erledigt im Falle des Ausfalls der Administrator per Image-Mounting.

Gegenüber einem herkömmlichen zyklischen Band-Backup hat aber selbst diese Lösung die Nase vorn. Wie auf der ersten wird auch auf dieser etwas niedrigen Hierarchiestufe jede Änderung der Daten sofort repliziert. Der Informationsbestand sieht also nach einem Recovery genau so aus wie vor der Störung.

Die Bandsicherung dagegen wird in der Regel einmal täglich vorgenommen. Im ungünstigsten Fall landet also die Arbeit eines kompletten Tages im Daten-Nirwana.

Datei unwiderruflich löschen?

Nicht selten erweist sich allerdings ein Mitarbeiter als gefährlicher als ein Brand oder Festplatten-Crash. Das Löschen einer wichtigen Mail kann zum Beispiel in einer Rechtsanwaltskanzlei durchaus dazu führen, dass ein Prozess verloren geht.

Mithilfe von speziellen Programme, etwa von Doubletake, kann der IT-Manager eine ausfallsichere IT-Infrastruktur mit Recovery-Servern aufsetzen und verwalten.

Auf die Failover- und Replikationstechnik allein ist in diesem Fall kein Verlass. Sie kann logische Fehler allenfalls auf das Backup-System duplizieren.

Wer sich auch gegen den Risikofaktor Mensch absichern will, braucht einen zusätzlichen Server und ein Programm, das die komplette Datenhistorie repliziert. Dann lässt sich jede Datei in jedem Bearbeitungszustand wiederherstellen – auch eine einzelne E-Mail. Auch hier gilt: Nicht jede elektronische Nachricht ist geschäftskritisch. Ist sie es aber, muss sie auch permanent repliziert werden.

Auch bei der Sicherheitspyramide sollte man die Basisarbeit nicht vernachlässigen. Kontinuierliche Replikation ist kein vollständiger Ersatz für das traditionelle Band-Backup. Tape-Streamer sichern die Backup Systeme; sie ermöglichen preiswerte, zyklische Langzeit-Backups.

Die niedrige Backup-Geschwindigkeit ist dabei ohne Belang. Die übergeordneten Replikationsebenen sowie ein Mehr-Generationen-Backup sorgen hier für eine immer noch ausreichende Redundanzquote.

Replikation ohne Datenstau

Datenänderungen einfach permanent zu replizieren, hört sich leichter an, als es ist. Einfach jede geänderte Datei komplett auf das Backup-System zu übertragen, wäre nicht die richtige Strategie. Denn das würde den Traffic im Netz viel zu stark aufblähen.

Außerdem könnten Änderungen erst nach dem Schließen der Datei repliziert werden. Problematisch wäre bei diesem Verfahren auch, dass Quell- und Ziel-Server oft unterschiedliche Hardware-Konfigurationen aufweisen.

Eine praktikable asynchrone Replikations-Lösung muss daher deutlich tiefer ansetzen. Moderne Hochverfügbarkeits-Software schickt daher, nach der einmaligen Vollsicherung zu Beginn, nur noch geänderte Daten über die WAN-Verbindung, und zwar auf unterster Ebene.

Übertragen werden tatsächlich nur diejenigen Bytes, die auf dem Primärsystem modifiziert wurden. Je nach Umgebung ist damit eine Replikation sogar über Standard-Internet-Verbindungen wie SDSL oder gar ADSL möglich, wobei die Daten via VPN-Tunnel vor unbefugten Zugriffen geschützt werden.

Da eine generische Replikation über Software, wie etwa die von Double-Take, lediglich I/O-Requests abfängt und übermittelt, ist sie völlig unabhängig von Applikationen und Hardware. Das Zielsystem muss in keiner Weise mit dem produktiven System identisch sein.

Zudem werden durch Replikation auch offene Dateien wirkungsvoll gesichert, was etwa bei Exchange-Servern oder SQL-Datenbanken zwingend erforderlich ist.

Auch für das Workload-Management

Virtualisierung heißt das neue Zauberwort in der IT: Prozesse werden durch eine Software-Zwischenschicht von der Hardware unabhängig und können auf virtuellen Servern beliebig im Netz verschoben werden.

Allerdings gibt es auch in der virtuellen Rechnerwelt ganz und gar reale Ausfälle. Daher ist es ratsam, ein tragfähiges Replikations- und Failover-Konzept gleich in den Virtualisierungsplan mit einzubeziehen.

Moderne asynchrone Replikationsprogramme funktionieren nicht nur auf physikalischen wie virtuellen Servern gleich gut, die effiziente Replikations-Technologie lässt sich auch bei der Verlagerung von Prozessen einsetzen.

Erst dann kann die virtuelle Umgebung ihre Vorteile ausspielen: Die Hardware wird besser ausgelastet und die Stromrechnung sinkt.

Krisenfest mit der Sicherheitspyramide

Gerade in wirtschaftlich schwierigen Zeiten ist es besonders schwierig, den Finanzvorstand oder Controller von einem Failover- und Desaster-Recovery-Konzept zu überzeugen. Hier liefert die Sicherheitspyramide in jedem Fall eine Basis für eine praxisgerechte Kosten-Nutzen-Analyse. Erst eine systematische Hierarchisierung zeigt, welches Maß an Verfügbarkeit man wirklich braucht.

Die Einteilung in unterschiedliche Prioritäts- und Sicherheitsklassen führt bei komplexen IT-Infrastrukturen allerdings dazu, dass mehrere Replikationsprogramme installiert werden müssen. Das wirft in jedem Fall die Frage nach der Kompatibilität auf. Experten raten davon ab, Software verschiedener Anbieter miteinander zu kombinieren.

Unvorhersehbare Wechselwirkungen treten nämlich meist dann auf, wenn man sie überhaupt nicht brauchen kann, im oft zitierten Disaster-Fall. Dieser lässt sich nicht vollständig simulieren und testen; zu groß ist die Anzahl der möglichen Ausfall-Kombinationen.

Bei der Wahl des Anbieters sollte man nach einem Failover-Spezialisten mit breitem und tiefem Sortiment Ausschau halten, etwa Double-Take Software [1]. Hier hat man die Gewähr, dass alle Komponenten reibungslos zusammenarbeiten – auch im ungünstigsten Fall der Fälle.

Kosten-Nutzen-Analyse im hierarchischen Stufenmodell: Welche Replikations-Software für welche Verfügbarkeitsstufe die richtige ist, zeigt die Kategorisierung in der Sicherheitspyramide.

Der Autor: Joachim Brebeck ist Marketingmanager DACH bei Doubletake Software.

[1] http://de.doubletake.com/

Verwandte Artikel