Datensicherung mit konsolidiertem Storage
Schnelle Backups für Außenstellen
Organisationen mit vielen Zweigstellen - national wie international - haben etliche Herausforderungen im Zusammenhang mit dem Management ihrer Datenbestände an diesen Orten zu meistern. Sie müssen entscheiden, ob sie die Daten lokal in der Außenstelle oder zentral im RZ sichern wollen.Die lokale Sicherung der Daten ermöglicht im Notfall eine schnelle Wiederherstellung, erfordert aber die Implementierung teurer und relativ aufwendig zu betreibender Speicher-Arrays und/oder Bandgeräte im den Außenstellen. Zudem entfällt hier die Möglichkeit geografisch verteilter Datenreplikation zur Notfallvorsorge (Disaster Recovery). Ein weiteres Problem ist es, flächendeckend verfügbares und finanzierbares IT-Personal zu finden, das derartige Dienste implementiert und am Laufen hält. Die Sicherung der Daten von Außenstellen im Rechenzentrum hingegen bietet die Möglichkeit eines geografischen Disaster-Recovery-Schutzes, erfordert aber kostspielige Sicherungssoftware in allen zu schützenden Bereichen. Zudem bremst es den Recovery-Prozess, wenn Daten über das WAN zurückzusichern sind. WAN-Optimierungstechnik kann hier Abhilfe schaffen. Ein neuer Optimierungsansatz für Backup-Prozesse ermöglicht es, Daten im Rechenzentrum zu konsolidieren und somit die dort üblichen Backup-Mechanismen zu verwenden. Dort gibt es auch genügend Personal, um die Speicherumgebung den Anforderungen entsprechend zu konfigurieren, zu warten und angemessen auf unvorhergesehene Ereignisse zu reagieren. So kann man im Prinzip auf Backup-Server und die dazugehörige Software in den Außenstellen verzichten. Im Kata-strophenfall lassen sich die Daten innerhalb kürzester Zeit zentral wiederherstellen und in die Außenstellen projizieren. Eine solche Lösung arbeitet mit herkömmlichen Sicherungs- wie auch mit aktuellen Storage-Array-basierten Snapshot-Methoden. Eine Lösung für konsolidierte Backups besteht aus zwei Bausteinen: Als Core-Komponente sorgt eine physische oder virtuelle Appliance im RZ für die Anbindung an das zentrale Storage-System. Am Netzwerkrand befindet sich eine Edge-Gegenstelle (Standalone-Appliance oder Softwaremodul auf einem WAN Optimization Controller/WOC). Das Core-Modul projiziert die RZ-Speicherressourcen (LUNs) in die Außenstellen, die ein Edge-System implementiert haben. Das Edge-Modul repräsentiert ein oder mehrere iSCSI-Targets in der Zweigstelle - diese stehen für Server-Ressourcen innerhalb und außerhalb der Edge-Appliance zur Verfügung. Der Core-Baustein besitzt File-System-Awareness (Erkennung von VMFS- und NTFS-Partitionen) und streamt mittels spezieller Block-Level-Prediction-Algorithmen Datenblöcke proaktiv zum Edge-System. So macht ein Unternehmen Daten auf zentralen Storage-Systemen an beliebigen Orten verfügbar, wann immer sie benötigt werden. Über asynchrone blockbasierte Beschleunigung von Schreibzugriffen stellt das Edge-Modul sicher, dass in der Außenstelle geschriebene Daten sicher im RZ gespeichert werden. In einem solchen Szenario existiert eine zeitliche Verzögerung (Time Lag) zwischen dem Zeitpunkt, an dem die Server in der Zweigstelle die Daten schreiben, und dem Zeitpunkt, zu dem die Daten im RZ ankommen. Das Edge-Modul quittiert deshalb alle Schreibzugriffe der Applikations-Server in den Außenstellen lokal und synchronisiert die geänderten Blöcke regelmäßig mit der Storage-LUN im RZ. Dies vermeidet Round-Trip-Delays, die sonst mit jedem Schreibvorgang anfallen würden - bei lokaler Performance sowie kontinuierliche Datensicherung für Applikations-Server in den Zweigstellen. Die Verzögerung im WAN hängt von mehreren Faktoren ab: WAN-Bandbreite, WAN-Latenz, Datenkompressionsrate, Datenveränderungsrate und Server-I/O in den Außenstellen. Die Verzögerung variiert je nach Server-Applikation und deren Last. Dies sollte man berücksichtigen. Es ist essenziell, das Konzept der Datenkonsistenz zu verstehen, wenn man Backup-Mechanismen für die Applikationen auswählt - insbesondere wenn es gilt, Kopien der Daten zurückzusichern und mit diesen weiterzuarbeiten. Zu beachten sind in der Regel zwei Typen der Datenkonsistenz: die Crash-Konsistenz (auch Point-in-Time-Konsistenz genannt) und die Applikationskonsistenz. Ein Backup oder Snapshot ist Crash-konsistent, wenn alle dazugehörigen Datenkomponenten so abgelegt sind wie zum Zeitpunkt des Crashs. Ein Crash-konsistentes Backup ist in der Regel akzeptabel für Datei-, DHCP- oder Druck-Server, jedoch weniger für Datenbank-Server. Applikationskonsistent sind Snapshots und Backups hingegen, wenn nicht nur die Reihenfolge der abgelegten Daten korrekt ist, sondern vielmehr die Applikationen auch die Möglichkeit hatten, die zu einem aktuellen Datensatz gehörenden Operationen abzuschließen und die Datenpuffer auf die Disk zu schreiben (Buffer Flush). Dieses Schreiben der Puffer bezeichnet man auch als "Application Quiescing", es ist vergleichbar mit der Festplatte einer Workstation nach dem ordentlichen Herunterfahren des Systems. Applikationskonsistente Backups empfehlen sich zum Beispiel für SQL-Datenbanksysteme. Datensicherungsstrategien Die Einführung von Konsolidierungstechnik für Backups in eine IT-Landschaft mit vielen Außenstellen ermöglicht es einem Unternehmen, bewährte Backup-Strategien weiter zu verwenden oder gar zu erweitern - also einer größeren Anzahl von Anwendern verfügbar zu machen, selbst in den Zweigstellen, die diese aufgrund der Bandbreite und Latenz der WAN-Anbindung bislang nicht nutzen konnten. Dabei sind eine Reihe von Optionen denkbar. 1. Weiternutzung Host-basierter Backup-Agenten in der Außenstelle: Die hier beschriebene Speicherkonsolidierung erfordert keine Veränderungen an existierenden Host-basierten Backup-Prozeduren, existierende Backup-Agents etwa auf virtuellen Servern sind weiter nutzbar. In diesem Szenario sorgt der Agent für das Application Quiescing. Danach wird dieser einen LUN-Snapshot anstoßen und diesen Satz von Daten zum Backup-Server schicken. Diese Sicherung ist dann applikationskonsistent, zusätzliche Daten müssen aber das WAN passieren. 2. Weiternutzung Host-basierter konsolidierter Backup-Prozeduren in der Außenstelle: Auch in diesem Fall sind keine Veränderungen an existierenden konsolidierten Host-basierten Backup-Prozeduren nötig. Diese Technik wird verwendet, um die mit den Backup-Agenten und -Prozessen verbundene Last von den Gast-Servern fernzuhalten. Der Backup-Server nutzt ESX-APIs für das Quiescing und das Erstellen des Snapshots der LUN. Der Backup-Server wird diesen Snapshot später mounten und sichern. Derartig erstellte Backups sind applikationskonsistent, aber auch hier müssen zusätzliche Daten das WAN passieren (wobei hier, wie bei Option 1, WAN-Optimierung helfen kann, die übertragene Datenmenge zu reduzieren). 3. Backup eines Crash-konsistenten LUN-Snapshots im RZ: Da die in der Außenstelle geschriebenen Daten ständig mit den LUNs im RZ synchronisiert werden, lässt sich das Storage Array im RZ dazu nutzen, Snapshots dieser LUNs zu generieren. Dies vermeidet überflüssige Datenübertragungen über das WAN. Sichern lassen sich die Snapshots entweder über eine mit dem Storage Array kompatiblen Replikationssoftware, NDMP-Sumps (Network Data Management Protocol) oder nach dem Mounten an einem Backup-Server. Enthalten die Snapshots VDMK-Dateien, ist ein ESX-Proxy-Backup-Server im RZ nötig, um den Datastore verfügbar zu machen und die zu sichernden Dateien dem Backup-Server zuzuführen. Da das Storage-Subsystem im RZ die Applikationen auf dem virtuellen Server in der Außenstelle vor dem Anstoßen des Snapshots nicht instruiert, laufende Operationen abzuschließen und die Puffer auf die Platte zu schreiben, sind diese Crash-, aber nicht applikationskonsistent. 4. Backup eines applikationskonsistenten LUN-Snapshots im RZ: Diese Option baut auf den unter Option 3 beschriebenen Prozessen auf. Zusätzlich nutzt man hier eine Microsoft-VSS-Integration (Volume Shadow Copy Service) in Verbindung mit Storage Array Snapshots. Dazu ist lediglich eine zusätzliche Software auf dem Windows Server in der Außenstelle zu installieren (ein so genannter Hardware Snapshot Provider). So können VSS-Snapshots einfach auf dem iSCSI-Datenlaufwerk des Windows Servers in der Außenstelle getriggert werden. Diese sind aufgrund der vorab beschriebenen Maßnahmen schließlich applikationskonsistent. Bei der Verwendung eines ESX-Servers in der Außenstelle ergibt sich eine analoge Vorgehensweise bei der Erstellung applikationskonsistenter Snapshots, ESX sorgt hier für das Application Quiescing. Die Sicherung der Snapshots erfolgt analog zu Option 3. Die Recovery-Prozeduren für die gesicherten Daten sind abhängig von der gewählten Datensicherungsstrategie.
Lesen Sie mehr zum Thema
