Warum sollte sich irgendjemand sorgen, dass im internen Netz Bandbreite zur Mangelware werde? Denn die Standardgremien, vorne weg die IEEE, entwickeln in immer kürzeren Zyklen schnellere Ethernet-Varianten, die jeden Kapazitätswunsch mit purer Durchsatzkraft ertränken. Erst 1 GBit/s, vergangenes Jahr 10 und bald 40 GBit/s. Sobald eine neue Generation des Frame-Verfahrens auf den Markt tritt, drückt sie die Preise für die alte. Die Investitionshöhe pro Megabyte fällt, oftmals in dramatischen Ausmaßen.

Ist es aber der einzige, konsequente Lösungsweg, mehr Bandbreite zu installieren, zu geringen Kosten? Oder müssen Administratoren bei der Wahl der Strategie inzwischen auch andere Faktoren einfließen lassen, die Bandbreite pur als ineffizient abstempeln? Tatsächlich ändern sich die Rahmenbedingungen. Schon heute generieren Applikationen größere Datenströme als vor zwei Jahren. Sie sprechen dabei nicht nur mit internen Plattformen und Clients, sondern mit Außenstellen, Partnern, mobilen Mitarbeitern. Allzu oft ist das WAN fester Bestandteil ihrer Kommunikationsketten. Gerade dieser Teil schwächt aber die bisherige »Bandbreite-pur-Strategie«. Denn das Medium WAN ist unberechenbar, eine Verfügbarkeitsgarantie gibt es nicht. Zudem wird WAN-Verkehr oft über schmalbandige Leitungen verschickt. Alle diese Faktoren nehmen Einfluss auf das Verhaltensmuster der Applikationen, des Netzwerkes und erschweren die Kalkulation. Dabei sind hier noch alle außergewöhnlichen Störfaktoren ausgeklammert. Große Wurm- oder Virenfluten verändern das Verkehrsmuster im Web radikal. Auch die wirtschaftlich schwierige Situation einiger Service-Provider wirkt sich auf die Verfügbarkeit des WANs und der Bandbreite aus. In den vergangenen Jahren haben einige durchaus große und etablierte Provider von einem auf den nächsten Tag aus finanziellen Sachzwängen heraus ihren Dienst einstellen müssen und alle angeschlossenen Kunden vom Netz gekappt.

Steckbrief

BIG-IP 2400

Hersteller: F5 Networks

Charakteristik: Layer-7-Switch

Kurzbeschreibung: Der Big-Ip greift frei definierbare Merkmale in der Payload von Web-Paketen auf, um auf ihrer Basis zu entscheiden, an welchen Server er die Anfrage weiterreicht. Daneben kann er SSL-Verbindungen terminieren, bekannte Würmer aufspüren und blockieren.

Web: www.f5networks.de

Preis: ab rund 6000 Dollar

Die Kontrolle des WANs und des darüber transferierten Verkehrs gewinnt vor diesem Hintergrund an Gewicht. Für Unternehmen, deren Applikationen kritische Daten über die externe Infrastruktur übertragen, spielt es eine wichtige Rolle, diese Strecken mit entsprechenden Mechanismen zu kontrollieren.

Die Industrie hat in den vergangenen Jahren mit der neuen Gerätekategorie »Layer-7-Switch« auf diese Anforderungen reagiert. Die Real-World Labs der Network Computing haben in Zusammenarbeit mit Broadband Testing zwei Geräte aus dieser Klasse einem Test unterzogen: den »BIG-IP«-Switch von F5 und den »9800«-Switch von Netscaler. Inzwischen haben beide Anbieter aktualisierte Software-Versionen vorgestellt und die Hardware-Architektur verbessert. Zum Testzeitpunkt befanden sich diese Versionen aber noch in der Betaphase und konnten daher nicht untersucht werden.

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, eine Kunst, die ihm bislang fehlte.

Beide Geräte wurden einer Reihe von Testverfahren unterzogen. Diese Ansätze waren auf die individuellen Funktionen der Switches zugeschnitten. Beide Switches haben dabei gute Ergebnisse erzielt.

BIG-IP 2400 von F5

Als F5 ihre Lösung zum ersten Mal vorstellte, war der Big-Ip-Switch ein konzeptionell einfaches Gateway-System, das Internet-Verkehr verwaltete und per Load-Balancing zwischen Servern, VPN-Gateways und Firewalls verteilte. Im Laufe der Zeit hat der Hersteller eine neue Generation vorgestellt, die als Switch konzipiert mehrere Gerätevarianten hervorbrachte. Der »BIG-IP 2400« ist für kleinere Umgebungen gedacht. Er besitzt 16 10/100-MBit/s- und zwei GBit/s-Ports und beschleunigt optional auf SSL basierenden Verkehr. Alle diese Switches wollen nicht mit dem Layer-3/4-Switches konkurrieren, sondern in Netzwerken eingesetzt werden, die stärker auf intelligente Verkehrsanalyse als auf Durchsatz pur angewiesen sind. Der Switch will vor Server- und Firewallfarmen, Cache-Systemen oder ähnlichen Anwendungen platziert sein. Dort kann er anfallende Lasten abhängig vom Verkehrstyp oder einem frei definierbaren Zustand verteilen, indem er dafür seine Traffic-Management-Funktionen einsetzt.

Eines der echten Benefits dieser Lösungen ist Content-Routing und -Switching. Layer-7-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 hat F5 zu diesem Zweck ihr »iRule«-Verfahren eingebettet, das für das Routing und Load-Balancing verantwortlich zeichnet. Diese Skript-Sprache erlaubt es dem Administrator, gewünschte, eindeutige Elemente in der Payload eintreffender Pakete auszuwählen und entsprechende Reaktionen zu definieren. Zusätzlich hat F5 mit ihrem »iControl« eine Integrationsarchitektur entwickelt. Mit Icontrol kann der Administrator eigene Anwendungen und Utility-Programme schreiben, die sich direkt an die Switch-Funktionen koppeln. F5 greift ebenfalls auf diese Software-Schnittstellen zu, um mehrere F5-Systeme zu integrieren.

Natürlich verlieren alle diese Funktionen ihren Effekt, wenn der Switch selbst nicht vor Ausfall gewappnet ist. Daher hat der Hersteller den 2400-Switch mit zahlreichen Funktionen ausgerüstet, damit das System Hardware-Fehler selbstständig überbrückt. Alle zielen darauf ab, den Single-Point-of-Failure zu beseitigen. In einer Konfiguration mit zwei Big-Ip-2400-Switches darf der Administrator mehrere Failover-Situationen definieren. Sowohl Stateful- als auch Persistence-Modi sind machbar. Der Hersteller gab eine Failover-Dauer von weniger als 0,07 Sekunden an. Der Test hat diesen Wert bestätigt.

Die Benutzungsoberfläche des Switches, mit der ein Administrator das System konfiguriert und verwaltet, hat überzeugt. Die Schnittstelle lässt sich sowohl von einem Web-Browser als auch per Kommandozeile ansteuern. Das Konfigurationswerkzeug ist einfach zu bedienen und robust. Selbst komplexe Konfigurationsschritte lassen sich zügig und direkt erledigen. Die Methode erinnert strukturell an eine Datenbank, in der man Objekte und Mehrfachoptionen verknüpft. Der Administrator muss also keinen Konfigurations-Code selbst kreieren.

Für den Intelligenztest des 2400-Switches wurden einige Einsatzfälle aufgesetzt. Die Tester verwendeten die Web-Server- und -Client-Simulatoren »WebAvalanche« und »WebReflector« von Spirent, mit denen sie den Testverkehr erzeugten. Im ersten Schritt sollte der Big-Ip HTTP-, HTTP/S- und FTP-Daten intelligent an spezifische Server durchreichen und mit seinen Load-Balacing-Künsten verteilen. Zusätzlich musste der Switch jeder Verkehrsklasse Werte zuweisen und Informationen extrahieren, die später Billing-Zwecken genügen sollten. Diese Konfiguration ist vor allem für Cost-Center-ähnliche Applikationen gedacht, bei denen der User dafür zahlt, wie lange er bestimmte Anwendungen nutzte.

Der erste Teil der primären Testkonfiguration (Load-Balancing) war schnell erledigt. Im Test wurde eine entsprechende Regel in der Management-Software aufgesetzt und der Switch hat erledigt, wozu er konfiguriert war. Für den zweiten Teil wurde per Icontrol ein Billing-System aufgesetzt, das auf TCP-Port-Basis den Big-Ip-Verkehr überwachte und ordnungsgemäß 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-Typen identifizieren musste. Es wurde eine Regel in Irule festgelegt, mit der der 2400 nach den entsprechenden Identifikationsmerkmalen in den Paket-Köpfen suchte, sobald er mit einer Streaming-Session konfrontiert wurde. 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 der Switch herausfinden, welche Verschlüsselungsstärke die jeweilige SSL-Sitzung verlangte, und sie dementsprechend an einen für 40 oder 128 Bit konfigurierten Server umleiten. Zu diesem Zweck wurde eine Regel aufgesetzt, die 128-Bit-Sessions mit einem Server verknüpfte, während alle anderen, schwächer kodierten Daten an einen anderen Server weitergereicht werden sollten. Die Webavalanche- und -Reflector-Simulatoren von Spirent haben die nötigen Verkehrsmuster generiert und an einen echten IIS-Server geschickt, der ebenfalls an den Big-Ip angeschlossen war. 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 Leistungseinbußen verkraftet.

In der nächsten Testphase wurde eine SQL-Slammer-Wurm-Simulation gestartet, um die Reaktion des Switches auf Angriffe zu beobachten. Wie bei allen anderen Verkehrsanalysen erkennt 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 des Switches untersucht, die F5 besonders hervorhebt. Der Hersteller sieht sie für den Alltagsgebrauch des Internet als besonders sinnvoll an. Die Funktionen sollen garantieren, dass trotz des dynamischen Load-Balancings 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. Die Simulatoren von Spirent haben dazu die nötigen Datenströme generiert. In allen drei Fällen hat Big-IP die Sessions kontrolliert und jeweils an den richtigen Mail-Server durchgereicht, indem der Switch die Client- und Server-IP-Adresse aufgriff und mit dieser Kombination die einzelnen Sitzungen und Teilnehmer identifizierte. Insgesamt hat der 2400-Switch alle Aufgaben, die der Test an ihn stellte, anstandslos erfüllt und war zudem einfach und direkt zu verwalten.

Steckbrief

Netscaler 9800

Hersteller: Netscaler

Charakteristik: Layer-7-Switch

Kurzbeschreibung: Der Netscaler-9000 nimmt externe TCP-Abfragen mit seiner TCP-Offload-Funktion selbst an und entlastet so dahinter liegende Server von dieser Aufgabe. Er terminiert SSL-Sessions, reduziert die Datenmenge per Kompression und cached oft angefragte Inhalte lokal.

Web: www.netscaler.com

Preis: ab rund 9900 Dollar

9800 Secure Application Switch von Netscaler

Der Anbieter Netscaler hat mehrere Switches im Portfolio, die durchwegs auf der gleichen Basisarchitektur aufsetzen. Der 9800-Switch ist in dem Highend-Bereich angesiedelt.

Netscaler trennt dabei das generische Betriebssystem FreeBSD von dem eigentlichen Geräte-Kernel, der den Großteil der Prozessanfragen beantwortet und ausführt. Daher entsteht im Gegensatz zu manch anderen Layer-7-Switches kein Overhead, sobald der Switch die Hilfe des Betriebssystems einfordert. Diese Arbeitsweise hat bei einigen Anwendungen wie SSL-Beschleunigung große Vorteile. Die Intention des Netscalers ist es, die Web-Applikationen zu sichern, dabei die höchste Verfügbarkeit zu garantieren und mehr Transaktionen mit noch höherem Tempo zu bewältigen. Am Ende soll der Betreiber Server-Ressourcen besser einsetzen können und künftig Geld sparen, weil er dank der Beschleunigung einige Hardware-Investitionen nicht tätigen muss.

Wo sitzt der Netscaler typischerweise im Netzwerk? Zwischen der externen Welt, sei es das Internet oder Intranet, und dem Datenzentrum, vor der Firewall, der Serverfarm und den Caches und so weiter. Der Switch leistet beiden Seiten seinen Dienst, sowohl bei ein- als auch ausgehenden Paketen. Interessanterweise besitzt der Netscaler trotz seiner prominenten Position wenige Ports, vier 10/100/1000-MBit/s-Varianten für interne sowie vier für externe Systeme. Damit er hochverfügbar arbeitet, ist seine Stromversorgung redundant ausgelegt. Ein Failover-Modus schaltet zwei Switches in einem Cluster zusammen.

Was dem Gerät zu Ruhm gereicht, sind seine »Request-Switching«-Techniken. Sie wollen Webverkehr so effizient wie möglich behandeln, indem sie die eintreffenden Daten analysieren und abhängig vom Anfrageniveau einer Applikation weiterleiten. Der Anbieter erklärte, dass sein Switch künftig auch in die Payload von Paketen schauen könne, um sich anhand dieser Daten für Routing-Pfade zu entscheiden. Die Funktionen, die bisher integriert sind, haben einen ausgezeichneten Eindruck gemacht. Dazu gehören TCP-Offload und -Optimierung, Datenkompression, statisches und dynamisches Caching, SSL-Beschleunigung, DDoS-Schutz und andere Intrusion-Prevention-Funktionen.

Der Administrator steuert den Switch einmal per CLI, das er für die erste Installation braucht, oder über eine grafische Browser-Oberfläche. Die GUI bildet zwar eine ganze Reihe von Switch-Funktionen ab, das CLI ist aber für einige Einstellungen unumgänglich. Der Administrator darf immerhin per Secure-Shell gesichert auf das FreeBSD-Betriebssystem zugreifen. Neben der grafischen Benutzungsoberfläche hat Netscaler ein »Dashboard«-Tool entwickelt, das statistische Monitoringdaten in Echtzeit darstellt. Diese Informationen zeigen die Leistungswerte und -einbrüche des Switches entweder in grafischen oder tabellarischen Formaten an.

Auch der Netscaler 9800 musste mehrere Testläufe bestehen. Die Verkehrsgeneratoren von Spirent erzeugten dazu den nötigen Verkehr. Der Switch musste diese Daten im Prinzip auf mehrere Server im Hintergrund verteilen, wobei er im ersten Lauf seine TCP-Offload-Fähigkeiten zu beweisen hatte. Die Idee hinter der Funktion: Ein Webserver verschwendet einen Großteil seiner Ressourcen damit, TCP-Anfragen zu beantworten. Die Folge ist, dass ab einer gewissen Anfragemenge seine Antwortzeiten darunter leiden. Der Netscaler fängt diese Anfragen vor den Servern ab und entlastet sie von dieser Arbeit.

Im Test hat überrascht, wie einfach sich dies konfigurieren ließ. Auch die Resultate verblüfften. Ein alter Pentium-II-Server wurde zum Supersystem. Indem der Netscaler ihn von den Anfragen befreite, stieg seine Leistung um 3000 Prozent. In anderen Worten: Der Server konnte mehr als 30 Mal soviel Verkehr verdauen als vorher. Selbst bei spezialisierten Pentium-IV-Servern hat der Test immerhin eine Leistungssteigerung um den Faktor 6 nachgewiesen. In der Praxis heißt dies, dass der alte Pentium II im Zusammenspiel mit dem Netscaler fünfmal mehr Performance auf die Leitung bringt als ein Pentium-IV-Server im Solo. Beim zweiten Testlauf – die SSL-Option – musste der Netscaler eintreffenden SSL-Verkehr lokal terminieren, statt dies den dahinter liegenden Servern zu überlassen. Der Switch erreichte folgende Resultate: Er hat von 345203 Versuchen 307745 Transaktionen erfolgreich abgeschlossen. Der Server hatte ohne Netscaler nur 11090 Erfolge bei 233029 Versuchen erreicht. Die Zahlen sprechen für sich.

Im dritten Test wurde eine 56-KBit/s-Modemverbindung simuliert, um einen schmalbandigen Zugriff auf HTTP-Anwendungen abzubilden. Dieser Lauf hat daneben auch Attachments erzeugt, um so die gesamten Kompressionsfähigkeiten des Switches untersuchen. Trotz Verkehrsanteilen, die durchaus kompressionsungeeignet waren, hat der Netscaler die Gesamtleistung der dahinter liegenden Server und die Antwortzeiten um rund 300 Prozent gesteigert. Danach wurde die Cache-Funktion untersucht, die der Switch ebenfalls lokal organisiert. Hier gelang es ihm, die Leistung der Infrastruktur um 400 Prozent zu steigern.

Der Netscaler ist dabei 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, hat die CPU-Auslastung kaum mehr als 25 bis 35 Prozent betragen. Das Gleiche galt für die Speichernutzung.

Fazit

Beide Layer-7-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 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.Steve Broadhead [ pm ]