Trotz immer schnellerer Ethernet-Varianten gewinnt die Kontrolle des WAN und des darüber transferierten Verkehrs immer mehr an Gewicht. Die Datenströme werden immer grösser, und WANs sind oft fester Bestandteil von Kommunikationsketten, die nicht nur mit internen Plattformen und Clients, sondern auch mit Aussenstellen, Partnern und mobilen Mitarbeitern verbunden sind. Und gerade dieser Teil schwächt die bisherige «Bandbreite-pur-Strategie». Das WAN ist ein unberechenbares Medium ohne Verfügbarkeitsgarantie. Zudem wird WAN-Verkehr oft über schmalbandige Leitungen verschickt. Alle diese Faktoren nehmen Einfluss auf das Verhaltensmuster der Applikationen und des Netzwerks und erschweren die Kalkulation. Hinzu kommen aussergewöhnliche Störfaktoren wie grosse Wurm- oder Virenfluten, die das Verkehrsmuster radikal verändern. Deshalb müssen Unternehmen, deren Applikationen kritische Daten über die externe Infrastruktur übertragen, diese Strecken mit entsprechenden Mechanismen kontrollieren können.
Mit der Gerätekategorie «Layer-7-Switch» hat die Industrie auf diese Anforderungen reagiert. Wir haben zwei Geräte aus dieser Klasse einem Test unterzogen: den BIG-IP-Switch von F5 Networks und den 9800-Switch von Netscaler. Diese Produkte konzentrieren sich nicht nur auf Durchsatz pur, obwohl dies natürlich wichtig bleibt, sondern wollen den ein- und ausgehenden Verkehr intelligent organisieren. Sie wollen die Daten so effizient wie möglich an ihr Ziel leiten, wobei sie illegalen oder unnötigen Verkehr blockieren oder umleiten. Dazu bearbeiten sie IP-Dienste und -Applikationen anhand von Informationen im Layer 7. Für Ethernet-Switches, was diese Geräte konzeptionell sind, ein durchaus wichtiger Evolutionsschritt. Denn auf diese Weise ergänzen sie das Frame-Verfahren um einen guten Schuss Intelligenz.
Beide von uns getesteten Switches setzen unterschiedliche Prioritäten und zeigen daher eigene Stärken. Falls man nach einem System sucht, das tief in der Payload individuelle Merkmale auslesen soll, dann ist der BIG-IP von F5 Networks die geeignete Lösung. Will der Administrator seine Server aber einfach und kosteneffizient entlasten, dann sind die simpel zu konfigurierenden TCP-Offload-Funktionen des Netscalers die bessere Alternative.
Der BIG-IP 2400 von F5 Networks ist für kleinere Umgebungen gedacht. Er besitzt 16 10/100-Mbps- sowie zwei Gbps-Ports und beschleunigt optional auf SSL basierenden Verkehr. Einer der echten Benefits von Layer-7-Lösungen ist Content-Routing und -Switching. Die Switches sind in der Lage, in den Inhalt der Pakete zu schauen und dank der gewonnenen Einsicht intelligente Routing-Entscheidungen zu treffen. Gerade bei HTTP-Verkehr ist dies sinnvoll, weil schon die URL-Adresse oder ein Cookie vieles über das adressierte Ziel aussagt. Im BIG-IP-2400 zeichnet das iRule-Verfahren für das Routing und Load-Balancing verantwortlich. Diese Skript-Sprache erlaubt es, gewünschte, eindeutige Elemente in der Payload eintreffender Pakete auszuwählen und entsprechende Reaktionen zu definieren. Zusätzlich hat F5 mit dem iControl eine Integrationsarchitektur entwickelt. Damit kann der Administrator eigene Anwendungen und Utility-Programme schreiben, die sich direkt an die Switch-Funktionen koppeln lassen. Der Switch ist mit zahlreichen Funktionen ausgerüstet, damit das System Hardwarefehler selbständig überbrückt. In einer Konfiguration mit zwei BIG-IP-2400-Switches können mehrere Failover-Situationen definiert werden. Sowohl Stateful- als auch Persistence-Modi sind machbar. Die vom Hersteller angegebene Failover-Dauer von weniger als 0,07 Sekunden wurde im Test bestätigt.
Für den Intelligenztest wurden einige Einsatzfälle aufgesetzt. Im ersten Schritt sollte der BIG-IP HTTP-, HTTP/S- und FTP-Daten an spezifische Server durchreichen und mit seinen Load-Balancing-Künsten verteilen. Zusätzlich musste der Switch jeder Verkehrsklasse Werte zuweisen und Informationen extrahieren. Der erste Teil der primären Testkonfiguration (Load-Balancing) war schnell erledigt. Nach dem Aufsetzen einer entsprechenden Regel in der Management-Software erledigte der Switch, wozu er konfiguriert war. Anschliessend wurde per iControl ein Billing-System aufgesetzt, das auf TCP-Port-Basis den BIG-IP-Verkehr überwachte und ordnungsgemäss die gewünschten Rechnungsdaten generierte.
In der zweiten Testphase wurden verschiedene Streaming-Media-Server aufgesetzt, die QuickTime- und Real-Player-Client-Anfragen beantworten sollten. Der Switch war gefordert, die verschiedenartigen Anfragen an den richtigen Media-Server durchzureichen, indem er den Client-Typ identifizieren musste. Es wurde eine Regel in iRule festgelegt, mit der das Gerät nach den entsprechenden Identifikationsmerkmalen in den Paketköpfen suchte. Der Switch hat diesen Testlauf problemlos bewältigt.
In der dritten Testphase musste der BIG-IP SSL-Verkehr terminieren, während er SSL-fremde Daten an die regulären HTTP-Server durchzureichen hatte. Gleichzeitig musste er herausfinden, welche Verschlüsselungsstärke die jeweilige SSL-Sitzung verlangte, und sie dementsprechend an einen für 40 oder 128 Bit konfigurierten Server umleiten. Während des Testlaufs wurde der Verkehrsfluss aufgezeichnet. Das geplante Verhältnis von 50 zu 50 zwischen kodiertem und unkodiertem HTTP-Verkehr wurde dabei eingehalten. Die verschlüsselten SSL-Pakete hat der BIG-IP terminiert, während er die Klartext-Daten an den angebundenen IIS-Server weiterreichte. Dabei hat die SSL-Terminierung des Switches die gesamte SSL-Leistung gesteigert. Der Zuwachs an Durchsatz ist schon dadurch zu erklären, dass der Switch weitaus mehr Ressourcen für die Kodierungspflichten besitzt als ein typischer Webserver. Der BIG-IP hat zwischen 1000 und 1100 Sessions pro Sekunde ohne Leistungseinbussen verkraftet.
In der nächsten Testphase wurde eine SQL-Slammer-Wurm-Simulation gestartet. Wie bei allen anderen Verkehrsanalysen erkannte der BIG-IP, um welche Pakete es sich handelt. In diesem Fall hat er dank der Paketinspektion den Wurmangriff identifiziert und alle Pakete abgewiesen, die den SQL-Slammer enthielten. Zu guter Letzt wurden die Persistence-Funktionen untersucht. Die Funktionen sollen garantieren, dass trotz des dynamischen Load-Balancing bereits etablierte Sessions an den Server geknüpft bleiben, der sie als erster bediente. Dies gilt unter anderem für eine POP3-Sitzung, die für ihre Dauer unbedingt denselben Server ansteuern muss, unabhängig davon, welche Probleme auftreten. Im Test wurde daher eine Regel festgelegt, die drei verschiedene Formen von POP3-Anwendersitzungen kontrollieren sollte. In allen drei Fällen hat BIG-IP die Sessions kontrolliert und jeweils an den richtigen Mailserver durchgereicht.
Insgesamt hat der Switch alle Aufgaben anstandslos erfüllt und war zudem einfach und direkt zu verwalten.
Der Testkandidat von Netscaler ist im High-end-Bereich angesiedelt. Das generische Betriebssystem FreeBSD wird vom eigentlichen Geräte-Kernel, der den Grossteil der Prozessanfragen beantwortet und ausführt, getrennt. Das hat zur Folge, dass kein Overhead entsteht, sobald der Switches die Hilfe des Betriebssystems einfordert. Die Hauptaufgabe des Switch ist die Sicherung der Webanwendungen. Dabei soll die höchste Verfügbarkeit garantiert und mehr Transaktionen mit noch höherem Tempo bewältigt werden.
Der Switch besitzt vier 10/100/ 1000-Mbps-Ports für interne sowie vier für externe Systeme. Die Stromversorgung ist redundant ausgelegt, und ein Failover-Modus schaltet zwei Switches in einem Cluster zusammen.
Besonderes erwähnenswert sind seine Request-Switching-Techniken, die Webverkehr so effizient wie möglich behandeln, indem sie die eintreffenden Daten analysieren und abhängig vom Anfrageniveau einer Applikation weiterleiten. Die in den Switch integrierten Funktionen hinterlassen einen ausgezeichneten Eindruck. Dazu gehören TCP-Offload und -Optimierung, Datenkompression, statisches und dynamisches Caching, SSL-Beschleunigung, DDoS-Schutz und andere Intrusion-Prevention-Features.
Auch der Netscaler 9800 musste mehrere Testläufe bestehen. Zunächst musste er Daten auf mehrere Server im Hintergrund verteilen, wobei er im ersten Lauf seine TCP-Offload-Fähigkeiten beweisen musste. Die Idee dahinter ist, dass ein Webserver einen Grossteil seiner Ressourcen damit verschwendet, TCP-Anfragen zu beantworten. Ab einer gewissen Anfragemenge leiden seine Antwortzeiten darunter. Der Netscaler fängt diese Anfragen vor den Servern ab und entlastet sie von dieser Arbeit. Dabei verblüffte die einfache Konfiguration genauso wie das Resultat. Ein alter Pentium-2-Server wurde zum Supersystem. Der Server konnte mehr als 30 Mal soviel Verkehr verdauen als vorher. Selbst bei spezialisierten Pentium-4-Servern hat der Test eine Leistungssteigerung um den Faktor 6 nachgewiesen. Beim zweiten Test musste der Netscaler eintreffenden SSL-Verkehr lokal terminieren, statt dies den dahinterliegenden Servern zu überlassen. Von 345'203 Versuchen hat der Switch 307'745 Transaktionen erfolgreich abgeschlossen. Ohne Netscaler konnte der Server nur 11'090 Erfolge bei 233'029 Versuchen verbuchen.
Schliesslich wurde eine 56-kbps-Modemverbindung simuliert, um einen schmalbandigen Zugriff auf HTTP-Anwendungen abzubilden. Dabei wurden auch Attachments erzeugt, um so die gesamte Kompressionsfähigkeit des Switches zu untersuchen. Trotz Verkehrsanteilen, die durchaus kompressionsungeeignet waren, hat der Netscaler die Gesamtleistung der dahinterliegenden Server und die Antwortzeiten um rund 300 Prozent gesteigert. Danach wurde die Cache-Funktion untersucht, die der Switch ebenfalls lokal organisiert. Hier konnte er die Leistung der Infrastruktur um 400 Prozent steigern. Zudem ist er in der Lage, alle diese Funktionen inklusive der SSL-Dienste simultan abzuwickeln. Selbst als er in einem Stresstest an die Grenzen seiner Kapazitäten gebracht wurde, haben sowohl die CPU-Auslastung wie auch die Speichernutzung kaum mehr als 25 bis 35 Prozent betragen.
