Startseite > Hardware > Praxis: Was beim Einrichten einer hoch verfügbaren IT-Infrastruktur zu beachten ist

Datensicherung: Hochverfügbarkeit im Kosten-Nutzen-Dreieck

Praxis: Was beim Einrichten einer hoch verfügbaren IT-Infrastruktur zu beachten ist

30. März 2009, 11:30 Uhr | Bernd Reder

Fortsetzung des Artikels von Teil 1

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.

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.

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.

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.

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.