Schneller zwischen Rechenzentren

Bislang wurden zwei Backup-Ansätze entwickelt und verfolgt: Der erste Ansatz, das lokale Backup
auf Bändern, erfordert, dass Tape Libraries überall dort lokal verfügbar sind, wo auch Server
vorgehalten werden. Über das LAN können Backup-/Restore-Prozesse schnell erfolgen. Der zweite
Ansatz, das zentralisierte Backup, sieht vor, große Tape Libraries mit sehr hoher Speicherkapazität
in der Unternehmenszentrale oder im zentralen RZ zu implementieren. Darauf werden die Daten der
unternehmensweit verteilten Server zentral gesichert.

Mit steigender Kapazität der Festplatten in Verbindung mit fallenden Preisen für Speichermedien
ist ein weiterer Trend im Bereich der Backup-Techniken aufgetreten: das Disk-to-Disk-Backup in Form
von Sekundärspeichersystemen und Virtual Tape Libraries (VTLs). Im Zusammenhang zum Beispiel mit
relationalen Datenbanken ermöglichen es die Snapshot-Techniken moderner Speichersysteme, Backup-
und Recovery-Zeiten noch weiter zu verkürzen. Die Backup-/Restore-Techniken fallen in die
Kategorien Full Backups, Incremental Backups, Differential Backups, Synthetic Full Backups sowie
Continuous Data Protection (CDP).

Um die Datenbestände in verteilten Rechenzentren synchron zu halten, kommen synchrone und
asynchrone Replikationstechniken zum Einsatz. Bei der synchronen Replikation werden Daten parallel
auf einem Source- und einem Remote-Speichersystem geschrieben; die Schreibanfrage auf dem
Quellsystem wird erst quittert, wenn der Schreibvorgang auf dem Zielsystem vollendet ist. Diesen
Anwendungsfall kann man bei Highend-SAN-Replikationsszenarien finden; dort sind in der Regel sehr
schnelle Datenverbindungen mit sehr geringer Latenz im Einsatz. Im Fall der asynchronen Replikation
können die Schreibvorgänge auf Quell- und Remote-System unabhängig voneinander erfolgen. Man
unterscheidet unter anderem zwischen Snapshot-, Block- und Byte-Level-basierten Methoden. Diese
Methoden funktionieren im LAN- oder MAN-Umfeld in der Regel sehr gut; problematisch wird es
allerdings, wenn die Latenzzeiten auf den Übertragungsleitungen steigen und zusätzlich noch im
Vergleich zum LAN/MAN viel geringere WAN-Bandbreiten verfügbar sind.

Um Speicherplatz auf den Speichermedien und Bandbreite auf den Übertragungsleitungen
einzusparen, kommen Daten-Deduplikationstechniken immer stärker zum Einsatz. Hier werden redundante
Datenmuster im Datenstrom aufgedeckt und elimiert. Die Sicht auf die Daten kann block-, datei- und
paket- oder Stream-basiert sein. Eine Datendeduplikation kann an der Quelle, über das Netzwerk oder
beim Schreiben auf ein Backup-Medium vorgenommen werden. Ruhende Daten lassen sich in Form einer
Nachbearbeitung dieser bereits abgelegten Daten deduplizieren. Diese unterschiedlichen Sichtweisen
auf die Daten resultieren in verschiedenen Effektivitätsgraden der Datendeduplikation.
Netzwerkbasierte Verfahren können die ursprüngliche Datenmenge bei idealen Bedingungen auf ein
Zehntel reduzieren. Erstmalig übertragene Daten können auf dem Transit mittels verschiedener
verlustloser Kompressionsverfahren reduziert werden, allerdings weniger effektiv als die
Datendeduplikation bereits bekannter Fragmente.

Im Zuge mit der zunehmenden Zentralisierung von IT-Diensten und einer Veränderung der
rechtlichen Rahmenbedingungen für die Datenhaltung (Compliance) sind die Vorteile eines
zentralisierten Backups offensichtlich, jedoch müssen sich die IT-Manager im Zusammenhang mit Data
Protection folgende Fragen stellen: In welchem Zusammenhang stehen die Bandbreitenanforderungen und
die Kosten eventuell zusätzlich benötigter Bandbreite? Wo liegt der Fokus: Recovery Point oder
Recovery Time? Hat man dedizierte Leitungen für die Data-Center-Replikation oder muss diese
Bandbreite mit anderen unternehmenskritischen Applikationen geteilt werden? In welchem Maße sind
die High-Speed Links zwischen Rechenzentrum und Backup-Rechenzentrum latenzbehaftet? Treten
Paketverluste auf? Ist es möglich, diese Leitung voll auszulasten?

Hat man beispielsweise für eine Datenmenge von 120 GByte ein Zeitfenster von acht Stunden,
sollte im Prinzip eine E3-Leitung (34 MBit/s) dafür ausreichen. Bei einem Delay von 100 ms hat
diese Leitung eine Kapazität (Bandwidth Delay Product, BDP) von 425 kBytes (zugunsten der
Übersichtlichkeit wurde hier 1 kByte = 1.000 Byte angenommen). Legt man für die Übertragung eine
TCP Congestion Window Size von 64 kByte zugrunde, benötigt man im Idealfall ohne Window Scaling
1,875 Millionen Roundtrips (120 GByte:64 kByte), um die Daten zu übertragen. Bei einer Round Trip
Time (RTT) von 100 ms werden dafür (ohne Berücksichtigung von TCP Slow Start und
Paketverlusten/Retransmits) über zwei Tage benötigt – das verfügbare Backup-Fenster wird damit
erheblich überschritten. Im Ernstfall würde man über zwei Tage verlieren, bis man wieder
einsatzfähig ist – mit alten Daten.

Hier ist es sinnvoll, über Möglichkeiten der Problemlösung nachzudenken, um das vorgegebene
Backup-Window einhalten zu können. Eine Möglichkeit ist natürlich, die Bandbreite zu erhöhen, oder
man ergreift Maßnahmen, um die verfügbare Bandbreite besser auszunutzen. Beim gegebenen Delay und
der verfügbaren Zeit für das Backup (oder den Restore-Vorgang), sind 8x60x60/0,1 = 288.000
Roundtrips möglich. Dies impliziert ein TCP Congestion Window von zirka 417 kByte. An dieser Stelle
wird es interessant, sich einmal genauer mit dem Thema WAN-Optimierung und -Beschleunigung zu
beschäftigen: Durch die Integration von WAN-Bescheleunigern ist es möglich, die über das WAN
übertragenen Daten so zu konditionieren, dass die vorgegebenen Ziele für die Übertragungszeiträume
erreicht oder noch weiter unterboten werden können.

Besonderheiten der RZ-Kopplung

Im Falle gekoppelter Rechenzentren mit angemessenen Disaster-Recovery-Mechanismen herrschen
andere Randbedingungen als bei der Außenstellenanbindung, die Büro- und Backup-Anwendungen im
Mischbetrieb über das WAN konsolidiert. Dies führt zu besonderen Anforderungen an das Design und
die Funktionen des WAN-Beschleunigers (WAN Optimization Controller, WOC). Rechenzentren sind in der
Regel mit sehr schnellen Leitungen, oft mit Geschwindigkeiten von über 100 MBit/s, miteinander
verbunden. Es werden wenige, oft aber langlebige Sessions zwischen den Sites aufgebaut. Oft werden
große Datenbestände übertragen, Last kann zufällig verteilt und sequenziell auftreten. Während es
bei relativ langsamen WAN-Verbindungen mit großen Delays oft darum geht, mittels intelligenter,
netzwerkbasierter Deduplikationsverfahren den Durchsatz dieser Leitungen zu erhöhen, geht es bei
solchen so genannten LFNs (Long Fat Networks) oft darum, die verfügbare Bandbreite überhaupt bis
zum Kapazitätsmaximum auszulasten.

Intelligente WOCs bieten hier die Möglichkeit, mit unterschiedlichen Parametern an die gesetzten
Ziele für effektive Bandbreite und Übertragungsfenster angepasst zu werden: Je nach Kombination von
Bandbreite und Delay sowie zu übertragenden Datentypen ist eine Kombination aus platten- und
speicherbasierten Deduplikationsverfahren, adaptiver Nutzdatenkomprimierung bis hin zur reinen
Anwendung unterschiedlicher High-Speed-TCP-Verfahren möglich. Welche Einzelverfahren oder
Kombinationen zum Einsatz kommen können, ergibt die Analyse möglicher Performance-Engpässe, die
sich aus den Charakteristika der eingesetzten Techniken ergeben: Lastverteilung auf verfügbare
CPU-Kerne, intelligente Verteilung von Wörterbucheinträgen für disk- und speicherbasierte
Deduplikation auf Massenspeichern und flüchtigen Speichern, Optimierung von Parametern für
Kompressionsverfahren und Datenpuffern auf Übertragungselementen wie Controllern und Routern
etc.

Im Zusammenhang mit HighSpeed-TCP-Verfahren spricht man auch gerne von "Fill-the-Pipe"
-Konfigurationen. Villamizar und Song haben sich schon 1994 (in "High Performance TCP in ANSNET?)
eingehend mit dem Thema der Optimierung von Datenpuffern auf Übertragungselementen befasst. Aus
deren Ergebnissen – wie auch zum Beispiel aus den Ausführungen von Van Jacobson in RFC 1072 sowie
im RFC 1323 – lassen sich Empfehlungen für die Dimensionierung ableiten: Bei einem Übergang von
einem (LAN-)Interface mit hoher Bandbreite mit niedriger Latenz auf ein Interface zum LFN mit
(relativ zum LAN) niedriger Bandbreite und hoher Latenz entsteht ein Flaschenhals. Um die Leitung
zu füllen, sollte zum Beispiel die Größe der Warteschlange auf dem nachfolgenden Router auf das
Äquivalent des BDP gesetzt werden.

High-Speed TCP und Cwnds

Die Zielsetzungen für High-Speed TCP (HS-TCP) sind an sich ideal für DR-Umgebungen: hoher
Durchsatz pro Verbindung bei moderaten Anforderungen an die Paketverlustrate, schnelles Erreichen
eines hohen Durchsatzes im Slow Start, schnelles (Wieder-)Erreichen hohen Durchsatzes beim Recovery
aus Multi-Retransmit-Timeouts oder Ramp-up aus Zeitfenstern mit kleinen Congestion Windows (Cwnds).
Dabei wird kein zusätzliches Feedback von Routern oder den Datenempfängern erwartet. Zusätzlich
soll die Performance äquivalent zu einer Standardimplementierung sein, sollte moderate oder höhere
Congestion mit Paketverlustraten von einem Prozent und mehr auftreten. Dazu wird die
Standard-TCP-Response-Funktion (siehe Kasten) modifiziert und auf Congestion-Control-Parameter
abgebildet: Der Congestion-Avoidance-Algorithmus spezifiziert einen Ansatz, in welchem jede
einzelne HS-TCP-Verbindung ihr Cwnd so verwaltet, als ob dieser Link eine aus mehreren
TCP-Verbindungen aggregierte Verbindung sei. So lässt sich dieses Fenster entsprechend den
Anforderungen von LFN-Umgebungen angemessen erweitern.

Zudem gibt es Verfahren, die den Congestion-Avoidance-Mechanismus außer Kraft setzen und bei
Paketverlusten Retransmits mit höchster Priorität übertragen, bei Riverbed MX-TCP (Bild Seite 46)
genannt.