Volle Breitbandseite ins Unternehmens-WAN

Schnelle Spiegelung und Replikation über IP-Netze

04.10.2007 | Autor / Redakteur: André Dieball / Nico Litzel

Konsolidierungsprojekte im Rechenzentrum, die Zweigstellen des Unternehmens mit besseren IT-Services versorgen sollen, scheitern nicht selten an der WAN-Infrastruktur. Selbst teure Leitungserweiterungen helfen nur in einigen Fällen. Grundlage von Misserfolgen sind nicht technische Fehlentscheidungen, sondern die inhärenten Mängel moderner Protokoll-Standards.

Zugriffe auf unternehmenskritische Anwendungen und Daten dürfen – schon vom psychologischen Standpunkt her – nach einer Konsolidierung nicht langsamer sein als davor. Ansonsten tendieren Benutzer dahin, nicht die zentrale CRM-Datenbank zu benutzen, sondern diese lieber durch eigene lokale Lösungen – wie beispielsweise Outlook – für die Kontaktdatenpflege zu ersetzen. Der spätere Datenbankabgleich wie auch die „Re-Versionierung“ der zahlreichen lokalen Dateikopien artet dann zur Sisyphusarbeit aus. Der Ärger über das rausgeschmissene Geld ist bei Administratoren wie Anwendern vorprogrammiert.

Doch wie kann garantiert werden, dass Nutzer in Niederlassungen oder auch mobile Nutzer performant und produktiv auf Daten in zentralen Rechenzentren zugreifen können? Hier hilft nur Ursachenforschung weiter, denn WAN-Zugriffe können immens beschleunigt werden. Wichtig ist es, die WAN-Anbindung als Ganzes zu betrachten. Die Ursachen für eine schlechte Performance liegen in den seltensten Fällen nur in der Bandbreite, sondern in der Summe aus:

  • Limitierter Bandbreite,
  • Ineffizienz des Transportprotokolls (TCP) und zu hohen Verzögerungszeiten
  • und der Ineffizienz des Anwendungsprotokolls (z. B. CIFS, MAPI, NFS, etc.).

Nur wenn all diese Punkte gemeinsam angegangen und deren negative Auswirkungen eliminiert werden, können WAN Verbindungen erfolgreich für Konsolidierungsprojekte optimiert werden.

Packeteer war mit einer der ersten Hersteller, die sich mit Traffic Shaping und anderen Funktionen um die WAN-Optimierung verdient gemacht haben. Aber auch andere Hersteller bieten mit eigenen Lösungen einige Möglichkeiten des flotten WAN-Zugriffs. Die folgenden Aussagen über die Beschleunigung von WAN-Verbindungen beruhen allerdings auf den Funktionen der Steelhead Appliances von Riverbed. Der Hersteller hat im RiOS-Betriebssystem (Riverbed Optimization System) mehrere leistungsfähige Module zur WAN-Optimierung in einer Appliance realisiert, die das Unternehmen innerhalb kürzester Zeit zu einem der Marktführer gemacht haben.

OSI-Stack für das WAN

Schneller WAN-Verkehr wird nach Riverbed im Normalfall auf vier Ebenen behindert. Jede funktionelle Verbesserung auf einer Ebene hat Anteil an einer letztlich erzielbaren Beschleunigung des Datenverkehrs (siehe Abbildung 1).

1. Ebene: Proxy File Services (PFS):

Die PFS-Funktion erlaubt es, auf den in den Niederlassungen eingesetzten Appliances lokale Shares einzurichten. Dadurch ist ein Zugriff auf Daten – je nach Konfiguration read-only oder read/write – möglich, auch wenn keine Verbindung zum zentralen Netwerkshare vorliegt. Hierbei handelt es sich also im Grunde genommen um einen Filecache. PFS ist grundsätzlich jedoch als ergänzendes Hilfsmittel zu sehen und nicht der primäre Einsatzzweck einer Steelhead Appliance.

2. Ebene: Scalable Data Referencing (SDR)

Der SDR-Algorithmus identifiziert sich wiederholende Datenmuster innerhalb von TCP-Verbindungen und referenziert diese durch 16 Byte große Referenzen. Wenn ein Datenteil als „neu“ identifiziert wird, wird dieser zusammen mit der Referenz an die in der Niederlassung stehende Appliance übertragen und dort auf Festplatte gespeichert. Bei sich wiederholenden Datenmustern wird dann nur noch die Referenz übertragen. Der Datenanteil, der diesen Referenzen zugrunde liegt, beträgt im Durchschnitt 128 Bytes, kann jedoch dynamisch auf bis zu 512 Byte wachsen.

SDR arbeitet mit einem vierstufigen Referenzmodell, das heißt, aus mehreren Referenzen kann wiederum eine einzelne Referenz erstellt werden. Bei diesem Modell ist es theoretisch möglich, bis zu 64 Gigabyte Daten durch eine einzige 16 Byte große Referenz zu übertragen, wobei 90 Prozent aller Berechnungen in den Stufen 1 und 2 stattfinden. Die neuen Datenanteile werden zudem noch vor der Übertragung komprimiert. Dadurch wird selbst bei „Einbahnstraßen-Verkehr“ eine Optimierung erreicht.

Der Effekt aus diesem Modell ist eine 65- bis 98-prozentige Reduzierung der übertragenen Datenmenge. Wichtig hierbei ist, dass SDR auf alle TCP-Verbindungen angewandt wird, das heißt, SDR macht keinen Unterschied, ob die Datenteile per CIFS, HTTP, FTP oder sonst einem Protokoll übertragen werden. Dadurch wird eine Protokollunabhängigkeit erreicht, die Riverbeds Ansatz deutlich von dem der Mitbewerber unterschiedet.

3. Ebene: Ineffizienz und Verzögerungszeiten von TCP

Die durch SDR für die Übertragung reduzierte Datenmenge wird zusätzlich noch durch Optimierungen des Transportprotokolls verbessert. TCP hat den – bezogen auf Übertragungen innerhalb eines WANs – Nachteil, dass es nach einer gewissen übertragenen Datenmenge eine Empfangsbestätigung verlangt, dass die Daten in korrekter Form erhalten wurden. Dieses Fenster liegt, je nach Implementierung des TCP/IP Stacks – zwischen 16 und 32 Kilobyte. Bei Verbindungen mit hohen Verzögerungszeiten verbringt der Sender sehr viel Zeit damit, auf eben diese Bestätigungen zu warten, anstatt Daten zu übertragen.

RFC-Standards erlauben die Anpassung dieser Datenmenge. Aufgrund der Tatsache, dass die Steelhead Appliances für Sender und Empfänger transparente, also nicht sichtbare, Proxy-Verbindungen über das WAN aufbauen, können diese RFCs (z. B. VWE – Virtual Window Expansion oder SACK – Selective Ackknowledgements) auf eben diese Verbindungen angewandt werden.

Durch die dynamisch, auf das WAN angepasste Vergrößerung des TCP-Fensters und SACK auf beispielsweise 100 Kilobyte und mehr und das „Füllen“ dieses Fensters mit Referenzen wird die Anzahl der benötigten Roundtrips für die Übertragung einer definierten Datenmenge um 60 bis 98 Prozent reduziert.

IP-Spiegelung von Storage Arrays ist erschreckend unproduktiv

Die Einbindung von HS-TCP (High Speed TCP) dürfte vor allem für Betreiber redundanter Rechenzentren interessant sein. Das Problem bei WAN-Verbindungen mit hoher Bandbreite (E3 und höher) bei gleichzeitig hoher Verzögerungszeit liegt in der ineffizienten Auslastung dieser Leitungen durch TCP. Das entspricht der häufig zwischen Rechenzentren eingesetzten STM-1-Verbindung zur Spiegelung von beispielsweise Storage Arrays. Auch wenn der Anwender lieber ein selbst verwaltetes Glasfaserkabel (Dark Fiber) bevorzugen würde, ist das aus Verfügbarkeits- oder Kostengründen meist nicht möglich. Dann bleiben nur die auf Standard-SDH basierenden TCP/IP-Verbindungen.

Storage Arrays nutzen für die Spiegelung über IP in der Regel wenige TCP-Verbindungen. Bedingt durch die Implementierung des TCP-Protokolls wird dadurch aber die maximal zur Verfügung stehende Bandbreite extrem eingeschränkt. Die benötigten großen Replizierungsfenster (ähnlich einem Backupfenster) führen die Anschaffung einer solchen Leitung jedoch ad absurdum.

Auch wenn Ihnen eine STM-4-Leitung mit 622 Megabit pro Sekunde zur Verfügung stünde, erhalten Sie bei 100 Millisekunden Verzögerungszeit mit einer einzelnen TCP-Verbindung nicht mehr als fünf Megabit pro Sekunde Durchsatz. Das ergibt sich aus dem sogenannten „Bandwidth-Delay-Product“ (BDP). Der Maximale TCP-Durchsatz errechnet sich somit aus „Fenstergröße geteilt durch Verzögerungszeit“. In unserem Beispiel also 64 Kilobit Fenstergröße geteilt durch 0.1 (100 Millisekunden Delay). Standard-Congestion-Control-Mechanismen verringern diesen Durchsatz weiter.

Riverbed hat in die Steelhead Appliances RFC-basierende Mechanismen eingeführt, um die TCP-Schwächen zu beseitigen und hoch performante TCP-basierende Verbindungen zwischen Rechenzentren zu ermöglichen.

Weitere, auf Standards basierende Implementierungen wie MAXTCP, TCP Vegas, Neural Framing oder Nagle sorgen für eine deutliche Verbesserung von TCP-basierenden Applikationen über das WAN.

4. Ebene: Applikationsspezifische Optimierungen

Leider reicht die Optimierung von TCP alleine nicht aus. Moderne Anwendungen nutzen Applikationsprotokolle wie CIFS, NFS, MAPI und an andere. Diese sind von ihrem kompletten Aufbau her absolut ungeeignet für den Transport über Leitungen mit limitierter Bandbreite und hohen Verzögerungszeiten.

Im LAN mit Bandbreiten von zehn Gigabit pro Sekunde und üblichen Verzögerungszeiten unter einer Millisekunde funktionieren diese Protokolle prima, bei Leitungsbandbreiten von zwei Megabit pro Sekunde und Verzögerungszeiten von 30 Millisekunden und mehr sind diese Protokolle fast nicht mehr arbeitsfähig. Das Problem liegt hier in der „Geschwätzigkeit“ eben dieser Protokolle und den dadurch verursachten enormen Roundtrip-Zeiten, die jede einzelne Operationen benötigt.

Für diese „Verdächtigen“ hat Riverbed über SDR und TCP-Optimierung hinausgehende Algorithmen und Methoden entwickelt. Diese reduzieren die benötigten Roundtrips – der eigentliche Grund für langsam erscheinende Verbindungen – um 65 bis 98 Prozent. Spezielle Methoden und Algorithmen stehen so für CIFS, NFS, MAPI, MS-SQL, Oracle, HTTP und HTTPS zur Verfügung.

Wer „seine“ Anwendung hier nicht findet, etwa Lotus Notes, sollte sich das verwendete Protokoll genauer ansehen. Lotus Notes zum Beispiel verwendet sehr „WAN-freundliche“ RPC (Remote Procedure Calls)“, die eine dedizierte Optimierung unnötig machen. Dennoch kann auch Notes durch SDR- und TCP-Optimierung um ein mehrfaches beschleunigt werden.

Mit der Optimierung von HTTPS hat Riverbed einen weiteren Punkt geschaffen, der den Ansatz deutlich von anderen Lösungen unterschiedet. Wichtig bei der Optimierung von HTTPS durch Riverbed ist, dass dabei nicht das „Ende-zu-Ende“-Security-Modell aufgebrochen wird. Eine Installation von „gefakten“ Rootzertifikaten oder gar einer Auslagerung des privaten Serverzertifikats ist nicht notwendig.

Einfache Installation, ausfallsicherer Betrieb

Trotz aller ausgeklügelten Modulfunktionen sind die Steelhead Appliances einfach zu implementieren und verwalten. Die Geräte werden in 80 Prozent aller Fälle zwischen Switch und Router „eingeschleift“ und sind anschließend transparent für Server und Clients, das heißt, es sind auch keine Änderungen in der bestehenden Konfiguration wie IP-Adressen, Networkshares, etc. vorzunehmen. Im Fehlerfall oder gar bei einem Komplettausfall verwandelt sich die Steelhead Appliance in ein – zugegebenermaßen recht teures – Crossover-Kabel. Der Rechenzentrumsbetrieb ist somit jederzeit gewährleistet.

Ausnahmen bestätigen die Regel. Die Einbindung einer Steelhead innerhalb des Datenpfades ist aber nicht immer, vor allen in den Rechenzentren selbst, möglich. Riverbed unterstützt hier die Umleitung von zu optimierendem Traffic per Policy Based Routing (PBR) oder Ciscos Web Cache Communications Protocol (WCCP). Eine redundante Implementierung als aktiv-aktiv oder aktiv-passiv ist in jeder Implementierungsform möglich. Durch den Steelhead-Interceptor oder WCCP/PBR ist auch Loadbalancing möglich. Das ermöglicht bis zu einer Million gleichzeitiger Verbindungen mit einer Gesamtbandbreite von 4 Gigabit pro Sekunde. Skalierbarkeit und Ausfallsicherheit sind somit ebenfalls realisierbar.

Neu hinzugekommen ist vor kurzem der Steelhead Mobil Client. Diese Software können Administratoren auf den Notebooks oder PCs von Mitarbeitern installieren, bei denen der Einsatz auch der kleinsten Appliance nicht möglich oder zu kostenintensiv ist. Dabei bietet der Mobile Client alle für einen einzelnen PC notwendigen Funktionen Eine zentrale Verwaltung und die Möglichkeit des transparenten Deployments gehören dabei zum „Pflichtprogram“ und werden selbstverständlich unterstützt. Somit können nun auch „Road-Warrior“ in das Optimierungskonzept mit einbezogen werden.

André Dieball ist Head of Technical Services and Storage bei der Berliner Zycko Networks.

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 2008121 / Grundlagen)