Die ständige Verfügbarkeit von Daten und zugehörigen Anwendungen ist heute kein schickes Accessoire mehr, sondern grundlegende Notwendigkeit jeder Storage-Strategie. Immer wichtiger wird in diesem Zusammenhang der Betrieb eines Ersatz-Sicherungsstandorts.

Datensätze und Anwendungen müssen sich im laufenden Betrieb replizierten und am zweiten Standort zusätzlich sichern lassen.

Ein Patentrezept für den richtigen Schutz gegen Daten- und Anwendungsausfall gibt es nicht. Vor allem drei Faktoren sind gegeneinander abzuwägen: Datensicherung vor Ort oder entfernt, tolerierbarer Zeitraum zur Datenwiederherstellung sowie Kosten für das Sicherungskonzept. Nimmt der Administrator die Backup-Bänder mit nach Hause, ist das vergleichsweise billig. Man hat zudem das Risiko von irreparablem Datenverlust am IT-Standort verringert. Allerdings dauert das Einspielen einer 750 Gigabyte großen Datenbank von Magnetband mehr als zwölf Stunden, wenn man eine durchschnittliche Transferrate von 15 MByte/s im Unternehmens-LAN annimmt. Es mögen bei kleineren Datenmengen ein paar Stunden weniger sein – so oder so sind die Daten nicht verfügbar und damit auch Geschäftsabläufe nicht, die von der IT-Unterstützung abhängen. Das trifft heute auf die Mehrheit der Prozesse zu, Tendenz steigend. Die Datensicherung an einem zweiten Standort gewinnt daher immer mehr an Bedeutung.

Spiegelarten

Ein solches Szenario kann so aussehen: Zunächst wird eine vollständige Kopie, die Replikation, der betreffenden Data-Volumes am Sekundär-Standort aufgesetzt. So kann dieser an Stelle des primären Standorts die Speicherung und Bereitstellung der Daten übernehmen. Der zweite Standort kann beliebig weit vom ersten entfernt sein. Nach der erstmaligen Replikation werden alle Datenänderungen am Hauptstandort kontinuierlich am Ersatzspeicherort abgeglichen.

Bei der synchronen Spiegelung, dem Synchronous-Mirroring, muss jede Datenänderung am primären Standort auf dem sekundären Speichermedium vollständig nachgezogen werden, bevor die zugehörige Anwendung fortfahren kann. Wie schnell der Vorgang ausgeführt wird, hängt von zwei Faktoren ab: Entfernung der Standorte und verfügbare Bandbreite für die Übertragung. Die synchrone Spiegelung bietet ein Maximum an Datensicherheit, das jedoch mit Performance-Abstrichen am Hauptstandort und in der Verbindung zur Secondary-Site erkauft wird.

Weniger Einfluss auf die System-Performance hat die asynchrone Spiegelung, das Asynchronous-Mirroring. Dabei werden mehrere Schreibvorgänge auf einmal überspielt, ohne auf das vollständige Nachziehen jedes einzelnen am Ersatzort zu warten. Dank immer leistungsfähigerer Storage- und Transfertechnologie sind Verzögerungen bei der Verfügbarkeit gebündelt überspielter Daten heute minimal.

Checkliste

Damit sich Konzepte zur Replikation und zum Disaster-Recovery (DR) im Ernstfall bewähren, sind verschiedene Aspekte bei ihrer Planung unbedingt zu beachten. Die erwähnten technischen Umsetzungen beziehen sich exemplarisch auf entsprechende Funktionsbereiche der Storage-Management-Software »IPStor« von Falconstor.

E Remote-Sicherung von DAS-Storage: Parallel zur Storage-Konsolidierung speichert die Mehrheit der Unternehmen immer noch einen Großteil ihrer Daten über Direct-Attached-Storage. Vor allem in Außenstellen und Home-Offices. DAS-Umgebungen haben den grundsätzlichen Nachteil, dass Backup- und Restore-Vorgänge mit erheblichem Administrationsaufwand verbunden sind. Sichert jeder Server, jedes Notebook und jedes andere Gerät auf ein eigenes Platten- oder Bandsystem, müssen jeweils die Backup-Software und Backup-/Restore-Agenten verwaltet werden. Übernimmt ein primärer Server die Sicherung für alle anderen, werden die LAN- oder WAN-Kapazitäten erheblich durch die Speicheraktivitäten belegt, was zu Performance-Abstrichen bei den Produktivvorgängen führt. Um die verschiedenen »Storage-Stränge« überhaupt mit vertretbarem Aufwand einer Remote-Sicherung zuführen zu können, müssen sie zunächst gebündelt werden. Dafür ist eine zentrale, vom eigentlichen DAS-Speicherort getrennte Storage-Management-Instanz notwendig, die kontinuierlich oder zu definierten Zeitpunkten auf die entsprechenden Daten in Außenstellen zugreift und in einem konsolidierten Storage-Pool sichert. Zur Vermeidung der LAN-Blockade und im Einklang mit immer kürzeren Backup- und Restore-Fenstern empfiehlt sich der Datentransfer über ein iSCSI- oder FC-SAN. Wichtig ist, dass der Sicherungsmodus für die Daten den jeweiligen Anwendungstypen entspricht und über entsprechende Agenten durchführbar ist. Für Datenbanken und Messaging-Systeme betrifft das die Block-basierte Sicherung, für andere Applikationen die File-basierte. Eine weitere Voraussetzung ist die transaktionale Integrität der zu überspielenden Daten. Sie muss ebenfalls über spezielle Agenten gewährleistet sein.

E Vorbereitende Maßnahmen gegen Systemausfälle – Datensicherung bei laufendem Anwendungsbetrieb: Gewöhnliche Backup-Software hat den Nachteil, dass Anwendungen zur Sicherung offline sein müssen. Es ist jedoch unwahrscheinlich, dass Systemausfälle warten, bis Daten und Anwendungen durch das Backup gelaufen sind. Zudem ist es bei vielen Geschäftsprozessen heute gar nicht mehr möglich, eine Systemauszeit für die Datensicherung zu nehmen – Stichwort »24x7«. Datensätze und Anwendungen müssen sich also im laufenden Betrieb replizierten und am zweiten Standort zusätzlich sichern lassen. Das geschieht durch Spiegelung einer laufenden Applikation auf einen zweiten Datenträger. Dieser wird dann offline genommen, um eine Sicherung durchzuführen. Geht er wieder ans Netz, müssen die Änderungen, die während des Speichervorgangs erfolgt sind, auf dem Spiegel-Datenträger nachvollzogen werden. Damit das in möglichst kurzer Zeit geschieht – die gespiegelten Daten müssen ständig für den Ersatzbetrieb bei Ausfällen am primären Standort zur Verfügung stehen – ist in der Storage-Management-Software eine so genannte Resync-Option notwendig. Sie protokolliert die Dateiänderungen während der Offline-Phase und erlaubt die schnelle Aktualisierung des gespiegelten Datenträgers, indem nur die seit der Offline-Sicherung geänderten Segmente aktualisiert werden. Das gleiche Prinzip kommt zum Tragen, wenn der Hauptstandort nach einem Zwischenfall wieder online gehen soll.

E Vorbereitende Maßnahmen gegen Systemausfälle – LUN-Zuweisung: Tritt ein Zwischenfall auf, stehen unvorbereitete SAN-Administratoren vor dem Problem, den Standby-Applikationsservern am zweiten Standort LUNs im sekundären Storage zuweisen zu müssen, um die Speichervorgänge dort fortzuführen. Dabei geht wertvolle Zeit verloren, bis der Ersatzstandort übernehmen kann. Es ist daher nötig, rechtzeitig die LUNs für die Ersatzserver zu definieren. Beim Systemausfall erhält die Replica-Disk sofort Primärstatus und die vordefinierten LUNs werden den nun zuständigen Applikationsservern am Ersatzort automatisch zugewiesen. Der SAN-Betrieb geht mit nur minimaler Verzögerung weiter.

E Maßnahmen gegen Zwischenfälle während der Replikation: Treten Systemausfälle mitten im Replikationsprozess auf, können Storage und Anwendungsserver am sekundären Standort den Betrieb nicht fortführen, wenn wie im synchronen Spiegelmodus erst alle Änderungen vollständig nachgezogen sein müssen. Im schlimmsten Fall stehen dann weder Haupt- noch Zweitstandort zur Verfügung. Das lässt sich verhindern, indem die replizierten Änderungen nicht direkt auf die Standby-Disk geschrieben, sondern an einem separaten Ort abgelegt werden. Der eigentliche Schreibvorgang erfolgt erst nach vollständiger und fehlerfreier Übertragung des gesamten Datensets.

E Maßnahmen gegen »schleichenden« Systemausfall: Unregelmäßigkeiten im primären Storagebetrieb machen sich oft erst nach einiger Zeit bemerkbar. Dann ist es schon zu spät, die Daten sind korrupt. Das gilt natürlich auch für die replizierten. In diesem Fall ist nur wenig gewonnen, wenn der zweite Standort nach dem kompletten Ausfall des ersten den Betrieb übernehmen soll. Die Datenkorruption im Sekundär-Storage muss daher möglichst schnell nach ihrer Entdeckung rückgängig gemacht werden. Hier hilft eine Variante des Snapshot-Prinzips: die »Zeitstempel«. Der Prozess erfasst in definierten Zeitabständen die Änderungen an Datenblöcken, versieht sie mit einer Zeitsignatur und speichert sie separat ab. Dieses Journaling-Prinzip hat den Vorteil, dass ein Abbild der geänderten Blöcke nur sehr wenig Speicherplatz benötigt und sich daher schnell sichern und replizieren lässt. Ist der Beginn der Datenkorruption ausgemacht, lässt sich der Zustand des Datenträgers vor dem Zwischenfall rekonstruieren, und zwar aus dem unmittelbar davor liegenden Journal-Eintrag, also den letzten gespeicherten »korrekten« Dateiänderungen, und dem ursprünglichen Datenträger, der als Sicherungskopie vorliegt. Die so rekonstruierte, korruptionsfreie Replica-Disk kann dann die Storage-Aufgaben am Sekundärspeicherort übernehmen, bis die Hauptsysteme wieder betriebsbereit sind.

E Kostenfaktoren bei der Replikation: Wie effizient Disaster-Recovery-Konzepte im Ernstfall sind oder ob sie überhaupt greifen, ist in erster Linie eine Frage der räumlichen Distanz zwischen Haupt- und Sekundärstandort. In vielen Fällen mag es genügen, Daten in den nächsten Brandabschnitt hinein zu replizieren. Nimmt das gesamte Gebäude Schaden, greift diese Strategie aber zu kurz. Bei zunehmender Entfernung des Replikationsziels tritt dagegen das Leitungsproblem auf: Hohe Durchsatzraten sind nötig, um das Storage-Laufwerk am »Streamen« zu halten. Viele Unternehmen unterhalten deshalb Standleitungen. Das ist ökonomisch meistens nicht sinnvoll, denn selten ist die zu replizierende Datenmenge so groß, dass sie die vorhandene Bandbreite wirklich ausschöpft. Hier sollte man sich nach dem tatsächlichen Bedarf richten. Gerade bei der asynchronen Spiegelung, wo kein kontinuierlicher Datentransfer erfolgt, genügt eine »dünnere« Leitung – auch für den Restore-Vorgang. Man kann etwa der zu übertragenden Datenmenge angemessene Kapazitäten in einer IP-Verbindung buchen, anstatt dedizierte Verbindungen über Dark-Fibre oder WAN-Leitungen wie SDH oder ATM zu bezahlen, die nur zu einem Bruchteil ausgelastet sind.

Guy Berlo, Geschäftsführer Falconstor Software