Ob SAN, NAS oder iSCSI: Die Technologien sind vorhanden und bieten gerade kleineren und mittleren Unternehmen eine gute Basis, um ihr wertvolles Informationskapital zuverlässig zu sichern. Beim Thema Backup empfiehlt sich generell die Überlegung, die Sicherungsprozesse in eine SAN-Struktur zu verlagern. Warum, das verdeutlichten herkömmliche Direct-Attached-Storage-Architekturen (DAS). Dort werden die Bandlaufwerke häufig als Shared Resources für verschiedene Server genutzt. "Abstriche bei der LAN- und Storage-Performance sind unvermeidlich, da der Datentransfer zwischen Backup-Server und Library über das lokale Netz erfolgt", erklärt Guy Berlo, Geschäftsführer bei FalconStor Software.
Damit ist jeder einzelne Sicherungsvorgang der LAN-Geschwindigkeitsbegrenzung unterworfen, die oft unter der optimalen Laufleistung des Bandlaufwerks liegt. "Über die Umsortierung und Verschachtelung der Datenpakete (Interleaving, Multiplexing) erlauben Datensicherungsapplikationen zwar mehrere simultane Backup-Streams zum Tape-Drive. Allerdings müssen die Backups über mehrere Anwendungs-Server hinweg koordiniert werden, was dem LAN zusätzliche Belastungen auferlegt und als unerwünschte Nebenwirkung die Restore-Zeiten verlängert. Die Backup-Applikation muss verschiedene Sessions abarbeiten, um die Daten für den entsprechenden Applikations-Server wiederherzustellen.
Dieser Engpass lässt sich durch ein SAN beheben. Dort erhält der Backup-Server eine wesentlich schnellere Verbindung für den Zugriff auf die Disc-Ressourcen der Applikations-Server. Zudem nutzt er diese im Schnitt auch wesentlich besser aus. Eine Studie von Merrill Lynch und McKinsey gibt das Auslastungsverhältnis von DAS- und SAN-Storage mit 50 zu 85 Prozent an. Das heißt, unter TCO- und Erweiterungsgesichtspunkten kann ein Unternehmen mit 35 Prozent mehr verfügbarem Storage im SAN planen.
iSCSI als Plattform für Backup-Architekturen
"Von der SAN-Option als Backup-Architektur ist der Weg zu iSCSI nicht mehr weit", meint FalconStor-Manager Berlo. "Der Standard hat sich als Ergänzung zu Fibre Channel (FC) und gerade für Klein- und Mittelunternehmen (KMU) als Einstieg in die SAN-Welt ins Gespräch gebracht." Dahinter steckt die Überlegung, die etablierten Protokolle SCSI für Speichermedien und IP für lokale und Weitverkehrsnetze zu verbinden und Speicherdaten über TCP/IP-Netze zu transportieren.
Da ein TCP/IP-LAN Datenpakete ohne Rücksicht auf Zeit und Reihenfolge überträgt, ein SAN dagegen Daten in Blöcken oder Blockserien auf dem kürzesten Weg in der ursprünglichen Ordnung transportiert, müssen die Datenblöcke für die TCP/IP-Bedürfnisse vom Server (im iSCSI-Kontext "Initiator" genannt) in Pakete umgesetzt werden. Das ist eine komplexe und prozessorintensive Prozedur, die in der Praxis sinnvollerweise vom Server auf separate iSCSI/Ethernet-Host-Busadapter (HBA) oder TCP/IP-Offload-Engines (TOE) verlagert wird. Dies entlastet das traditionell Overhead-behaftete Ethernet.
iSCSI: Kostenvergleich
"Auch wenn die Durchsatzraten noch weit von denen für Fibre Channel entfernt sind, ist iSCSI für Backup-Strategien guten Gewissens zu empfehlen", erläutert FalconStor-Manager Berlo. "Hersteller bieten heute schon iSCSI-HBAs für einige Hundert Euro an, im Schnitt zwei Drittel günstiger als die FC-Pendants." Auch die Anschaffungskosten für Switches und Router liegen für iSCSI weit unterhalb des FC-Niveaus.
Der Distributor Esesix hat in einem Kostenvergleich ermittelt, dass iSCSI-Speichernetze generell bis zu 50 Prozent günstiger sein können als die FC-Varianten für die gleichen Anforderungen. Zudem erhöhen sich die Einsparpotenziale überproportional, je mehr Server vernetzt sind - ein nicht unerheblicher Aspekt angesichts der zu erwartenden Storage- und Backup-Bedürfnisse. Nicht unerheblich über die Anschaffungskosten hinaus ist auch, dass iSCSI-basierte Netze in Konfiguration, Handhabung und Erweiterung um einiges "pflegeleichter" sind, da sie mit für Systemadministratoren vertrauten Standards operieren.
Backup-Medium: Platten oder Bänder?
"Wer von kostengünstigen Lösungen für die Datensicherung spricht, muss über die Vernetzung von Applikations- und Backup-Servern hinaus auch an die Sicherungsmedien selbst denken", argumentiert FalconStor-Manager Berlo. "Dieser Bereich firmiert gewöhnlich unter dem Stichwort Disc- versus Tape-basiertes Backup. Ähnlich der iSCSI/Fibre-Channel-Thematik ist auch hier eine pauschale Entweder-oder-Betrachtung nicht angebracht."
Der anhaltende Preisverfall von Platten gegenüber Bändern entziehe dem Argument den Boden, wonach gerade kleinere Unternehmen alleine aus Kostengründen an die Bandsicherung "gekettet" seien. Eine sehr allgemeine Unterscheidung kann lauten: Tape-Libraries sind heute für die langfristige Archivierung, Disc-basiertes Backup - auch Backup-to-Disc oder Disc-to-Disc (D2D) genannt - für die primäre Datensicherung prädestiniert.
Vorteile eines Disc-to-Disc-Backups
Die Berechtigung von D2D-Konzepten ergibt sich aus einem Blick auf den Backup-Alltag: Herkömmliche Sicherungskonzepte weisen alle Vorgänge (Backup, Restore, Archivierung) einer einzigen Komponente zu, in der Regel dem Tape-Drive oder der Bandbibliothek. Das Backup einer 750 GByte großen Datenbank dauert auf diese Weise bei einer durchschnittlichen Transferrate von 15 MByte/s über zwölf Stunden. Pro Arbeitstag ist also nur eine Backup-Session möglich. Steht ein Restore an, werden ebenfalls über zwölf Stunden benötigt. "Es entsteht im ungünstigsten Fall ein "Risikofenster" von 24 Stunden, bis das nächste Backup durchgeführt werden kann", erklärt Berlo. "Auch wenn es ein paar Stunden weniger sind, können die wenigsten Unternehmen ihre ständig steigenden Datenmengen diesen Bedingungen heute noch aussetzen."
D2D-Backup setzt bei der Trennung von Produktivdaten und Sicherungsapplikationen gegenüber dem Archivierungssystem an. Das Speicherziel ist zunächst nicht das Bandlaufwerk, sondern ein Disc Array, das alle Vorteile von Festplatten-Clustern bietet: RAID-Funktionalität, Highspeed-Datentransfer im FC/IP-SAN, Random Access. Gesichert wird gewöhnlich über Journal Replication (Point-in-Time-Backup) oder Snapshot Replication, also kontinuierlich oder zu bestimmbaren Zeitpunkten. Damit lässt sich das genannte Risikofenster weit gehend schließen. Im Restore-Fall der 750 GByte großen Datenbank ließe sich ein aktuelles LUN Snapshot-basiert auf einen früheren Zustand in rund 20 Minuten zurückfahren (bei angenommenen zehn Prozent Änderung und einer I/O-Rate von 60 MByte/s).
Für den Transfer der zwischengespeicherten Daten zum Bandmedium (Disc-to-Disc-to-Tape, D2D2T) übernehmen die Disc Arrays Cache-Funktion. "Über Fibre Channel oder iSCSI lässt sich das Caching sehr schnell durchführen", konstatiert FalconStor-Manager Berlo. "Die Daten werden dann zu einem späteren Zeitpunkt auf die Tape-Library überspielt." Die Prozesse benötigen jedoch einige Administratoreingriffe. Individuelle Backup-Server müssen für die D2D-Funktionalität konfiguriert, iSCSI/Fibre-Channel-Storage für das Caching der Backup-Daten zugewiesen werden. Unterstützung liefern entsprechende Tools, die den Backup-Servern Plattenkapazitäten "On-Demand" zuweisen. Als Faustregel gilt hier, dass der benötigte Pufferspeicherplatz das eineinhalbfache (Snapshot Replication) beziehungsweise dreifache (Journal Replication) des Online-Disc-Speichers benötigt.
Virtuelle Backup-Alternative
Wer den Aufwand scheut, sollte den so genannten Virtual-Tape-Ansatz beachten. "Ein Disc Array wird dabei zur Emulation einer Bandbibliothek verwendet", sagt FalconStor-Manager Berlo. "Virtuelle Bandlaufwerke/Libraries lassen sich generieren und Applikations- oder Backup-Servern im Fibre-Channel- oder IP-SAN zuweisen, als wären sie physische Medien." Jeder Backup-Server kommuniziert so mit einem festgelegten Laufwerk, das er nicht mit anderen teilen muss. Änderungen an der Backup-Konfiguration sind nicht nötig. Mehr Geschwindigkeit entsteht, indem die Sicherungsvorgänge simultan über mehrere Kanäle durchgeführt werden.
Was die Kapazität angeht, kann man für ein Disc Array (Referenz: Apple Xserver RAID) den Faktor sieben bis 40 gegenüber gängigen Bandbibliotheken (Referenzen: DLT, SDLT, LTO-1/2, AIT-3, SAIT, STK 9940) veranschlagen. Beim Durchsatz liegt der Plattenverbund ebenfalls um mindestens das Zehnfache darüber.
Nimmt man als Beispiel eine Emulationslösung (Referenz: IPStor VTL für iSCSI), die in ihrer Grundkonfiguration zwischen zwei und zehn Bandbibliotheken virtuell bereitstellt, und deren Durchsatz ebenfalls um einiges höher ist, lassen sich deutliche Einsparungen erzielen. Vorausgesetzt, man vergleicht die Aufwendungen für Disc Array und Virtual-Tape-Lösung mit denen für weitere physische Bandgeräte sowie deren virtuelle Kapazität.
NAS: Die preisgünstige Backup-Lösung
Geht es um das Preis-Leistungs-Verhältnis bei Backup-Konzepten, hat sich in jüngster Zeit ein alter Bekannter zurück ins Rampenlicht gespielt: Network Attached Storage (NAS). "In einer letztjährigen Erhebung von Gartner Dataquest nannte ein hoher Prozentsatz der befragten KMU-Unternehmen die Fileservice-Variante als den bevorzugten Weg für flexiblen temporären Speicher und Disc-to-Disc-Backup", erklärt FalconStor-Manager Berlo. "Auffallend viele Freunde hat NAS in der Gruppe der Unternehmen mit bis zu 100 Angestellten." Das hat gute Gründe: In einer NAS-Architektur sind die Fileserver und die daran angeschlossenen Plattensysteme auf die Bereitstellung von Dateien optimiert. Dafür besitzen sie in der Regel ein abgespecktes Betriebssystem, das sich auf die notwendigsten Schnittstellen beschränkt und operieren innerhalb der LAN-Strukturen. Das kommt gerade kleineren Firmen und Unternehmenszweigen entgegen, die eine konsolidierte Storage-Umgebung betreiben möchten, aber nur beschränkte Administrationskapazitäten aufbringen. Nicht unerheblich ist in dieser Hinsicht, dass die Server plattformunabhängig auf NAS-Daten zugreifen (True Data Sharing).
"Was die Performance angeht, verarbeiten NAS-Systeme heute mehrere Tausend I/Os pro Sekunde mit guten Response-Zeiten, da sie die Read/Write-Operationen für Dateidienste von denen für Anwendungen trennen und damit CPU-Überlastungen verhindern", erläutert FalconStor-Manager Berlo. "Die generelle Einschränkung beim Storage Pooling auf die jeweilige NAS-Einheit - jeder User erhält beim Zugriff auf ein Filesystem dort, und nur dort, Speicherplatz nach Bedarf zugewiesen - führte zur Idee der Trennung von Filesharing-Intelligenz (NAS-Head) und Storage-Komponente." Der NAS-Head lässt sich dann als Gateway mit einem SAN verbinden; dessen Storage-Pool kann auch für Fileservices genutzt werden. Das Gateway empfängt einen File-I/O-Request über die Protokolle NFS und CIFS und übersetzt ihn in einen SCSI-Block-I/O-Request, um die Platten im Storage-Pool anzusprechen.
Windows Storage Server 2003
Neuen Schwung erhielt die NAS-Debatte mit der Veröffentlichung von "Windows Storage Server 2003". Das Microsoft-Produkt ist eine spezielle NAS-Version des Betriebssystems Windows Server 2003 und Nachfolger des Windows 2000-basierten Windows Powered NAS - auch als Server Appliance Kit 2.0 bekannt. Das Betriebssystem unterstützt für das Filesharing SMB/CIFS, NFS, Apple Talk und Netware-Protokolle. Nach Microsoft-Angaben können in einem Storage-Server rund zehn Fileserver konsolidiert werden. Die NAS-Variante wird von Microsoft nur an zertifizierte OEM-Anbieter geliefert, die sie in ihre Speicherlösungen integrieren und als Komplettpakete anbieten. Gerade für Klein- und Mittelunternehmen ergeben sich auf diesem Weg interessante Optionen, um beispielsweise Mail-, File- und Printserver zentral über ein NAS zu sichern.
"Soll Windows Server 2003 als Gateway zum SAN fungieren, ist die Funktion "Virtual Disc Service" (VDS) der Ansatzpunkt", erläutert FalconStor-Manager Berlo. "VDS ist Teil des Volume Managers und liefert eine Standardschnittstelle zu den an den Server angebundenen Datenträger- und Storage-Systemen." Die Schnittstelle überwacht die Bereitstellung von Festplatten und zeigt sie dem Server als physisches oder virtuelles Laufwerk an. VDS selbst bringt keine neuen Virtualisierungs-Features mit, es nutzt das in Windows 2000 enthaltene Dynamic-Discs-Prinzip. Dynamic Discs bestehen aus logischen Partitionen (Volumes), denen Laufwerksbuchstaben zugeteilt werden. Volumes können als RAID 0 (striped), RAID 1 (mirrored) und RAID 5 (striped-parity) generiert werden.
Hybride Storage-Backup-Lösungen
An dieser Stelle kommen Lösungen von Drittherstellern ins Spiel, die auf Basis des Windows-2003-Betriebssystems die Disc-Storage-Aggregation über den NAS-Bereich hinaus ermöglichen und damit auch für Backup-Strategien ganz neue Wege ebnen.
FalconStor hat diese Funktionalität in seinem "iSCSI Storage Server" umgesetzt. Dabei werden Fileshares und virtuelle Block-Level-Discs generiert und in einem konsolidierten Storage-Pool via iSCSI/Ethernet bereitgestellt. "Das ist zum Beispiel hilfreich, wenn in größeren Unternehmen unterschiedliche Storage-Bereiche für die Verwaltung zusammengefasst werden sollen, wie Abteilungs-NAS und primäres SAN im Rechenzentrum", konstatiert FalconStor-Manager Berlo.
"Die Verzahnung geographisch verteilter Standorte profitiert ebenfalls vom Storage-Hybrid, diese umgeht SAN-immanente Reichweitenbegrenzung", so Berlo. Schließlich kann sich das so generierte Disc-Storage für NAS und iSCSI dasselbe RAID-Array teilen, was zusätzliche Kosten- und Aufwandsminderung bei der Administration bedeutet.
Ausblick und Fazit
Eine neue Grundlage für flexible Sicherungsprozesse auf Basis von Windows Storage Server 2003 ist die Snapshot-Funktion "Volume Shadow Copy Service" (VSS). "Snapshots spielen eine zentrale Rolle für Replikations- und Recovery-Strategien in der SAN-Welt", meint FalconStor-Manager Berlo. "Während VSS selbst die "Schattenkopien" nur auf File-Ebene nimmt und auf 32 Snapshots pro Volume beschränkt ist, lässt sich die Funktion mit Hilfe einer entsprechenden Windows-2003-basierten Third-Party-Managementlösung auf Block-Level ausweiten und beispielsweise für Replikationsszenarien mit einem zweiten Standort verwenden." Dabei wird etwa ein iSCSI-LUN über IP zum Remote-Server repliziert. Dort erfolgten das Journaling der replizierten Laufwerke und die Erstellung der Snapshots.
Eine sinnvolle Variante besteht darin, nur die Abbilder der geänderten Datenblöcke zu erstellen. Dies beansprucht verhältnismäßig wenig Speicherplatz - in der Regel genügen ein bis fünf Prozent des Datenträgers - und führt im Störfall zur wesentlich schnelleren Datenrettung. Steht der Zeitpunkt der Störung fest, lässt sich aus einem zuvor genommenen Snapshot und dem ursprünglichen Datenträger ein Abbild ermitteln. Dieses kann zum primären Standort, mit dem man weiterarbeiten kann, überspielt werden, als ob der Zwischenfall nicht stattgefunden hätte.
In diesem Kontext ist es auch sinnvoll, dass die erweiterte Snapshot-Funktionalität Lese- und Schreibzugriff erlaubt. Mit VSS alleine ist nur "read-only" möglich. Bei Lese- und Schreibzugriff können jederzeit "virtuelle" Kopien oder Replikationen eines aktiven Datensets erstellt und mehreren Applikations-Servern zur Verfügung gestellt werden. Zusätzlich erlaubt die Funktion dem ursprünglichen Server, das Originalset weiterhin zu nutzen. FalconStor-Manager Berlo erläutert: "Das macht die Snapshots für weitere nützliche Prozesse tauglich, etwa für Testszenarien bei Erweiterungen der Storage-Architektur, die parallel zum regulären Betrieb ablaufen können." (hal)
Dieser Artikel basiert auf einem Beitrag von speicherguide.de.