Von Johann Baumeister*
Radwares Highend-Appliance
Der App Director (AppDir) von Radware zählt zu den umfangreichen und teuren Balancing-Systemen. Die Appliance basiert auf Asics, Netzprozessoren und eigener Firmware.
Der AppDir arbeitet auf den Ebenen zwei bis sieben und ist damit in der Lage alle Protokolle zu analysieren. Dies sind unter anderem die Mail-Dienste, FTP, http, aber auch DNS, DHCP oder Voice-over-IP. Möglich ist zudem die Auswertung nach Port-Adressen (Layer 4) oder URLs, übermittelten Cookies und frei wählbaren Inhalten.
Die Kriterien zur Lastverteilung reichen von Session pro Server, Download-Volumen, Durchsatz des Servers, Benutzeranzahl, Server-Auslastung bis hin zur Antwortzeit oder Geschwindigkeit beim Aufbau einer TCP-Session. Durch Scripting ist die Auslastung periodisch zu prüfen.
Konzeptionell geht Radware davon aus, dass für einen Dienst mindestens zwei in einer Farm zur Verfügung stehen. Das System ist in der Lage, mit maximal 10 000 Farmen zu operieren.
Um den Balancer selbst gegen Ausfälle abzusichern, kann er im Cluster mit maximal 254 Einheiten betrieben werden. Die Kommunikation der Balancer untereinander erfolgt über das VRRP (Virtual Router Redundancy Protocol) oder über eine proprietäre Kommunikationsschicht. In beiden Fällen werden die Session-Tabellen untereinander ausgetauscht.
Das Management ist rollenbasierend und wird über eine zentrale Konsole vorgenommen. Alternativ stehen die Protokolle Telnet, SSH, http oder HTTPS zur Verfügung. Über SNMP-Traps und die zugehörigen MIBs (Management Information Bases) lassen sich andere Management-Konsolen etwa von CA Unicenter, BMC Patrol, HP Openview oder IBM Tivoli einzubinden.
Zusätzlich zum Load Balancing hat der Hersteller weitere Funktionen implementiert. Hierzu zählt die Priorisierung von Applikationen, um deren Verfügbarkeit zu erhöhen. Ferner ist AppDir mit einem Intrusion-Prevention-System ausgestattet, das auch DDoS-Angriffe abwehren kann. Schließlich sind auch Features für das Bandbreiten-Management eingebaut.
Besonderheiten
-- Umfangreiche Funktionen für Balancing;
- weite Abdeckung von Layer 2 bis Layer 7.
- Relativ wenig Auswahl- kriterien für die Lastverteilung.
BIG-IP regelt den Verkehr
Eine Traffic-Management-Lösung bis zur Ebene sieben des ISO/OSI-Modells hat F5 Networks mit BIG-IP im Angebot. Bezüglich der untersuchten Protokolle offeriert die BIG-IP damit auch das gesamte Spektrum der im Internet verwendeten Protokolle.
Die Lastverteilung lässt sich nach vielfältigen Kriterien vornehmen. F5 selbst positioniert das Produkt weniger als Balancer, sondern spricht von einem Werkzeug für das Traffic-Management beziehungsweise von einem Tool für Web Application Optimization. Dazu zählen die Kompression der Inhalte von HTML-Seiten, die Integration von Proxy-Funktionen für einen nachgeschalteten Web-Server, SSL-Offloading oder die Optimierung der TCP/IP-Kommunikation durch Protokolländerungen etwa der "Window Size" eines IP-Paketes.
Die paarweise Verwendung bietet interessante Zusatzoptionen
Integriert in die Appliance sind Sicherheitsfunktionen, die DDoS-Attacken abwehren. Das Produkt besitzt ferner Schnittstellen zu wichtigen Datenbanken und Application-Servern (Oracle, Microsoft und Bea) sowie zum CRM-System von Siebel. Diese Schnittstellen ermöglichen die Konfiguration der Appliance aus der Anwendung heraus. Durch die integrierte Skriptsprache iRules sind dynamische Konfigurationen möglich.
Die Appliance selbst bietet, paarweise verwendet, Ausfallsicherheit mit Failover-Funktionen. Dies lässt sich auch als globales Load Balancing über WAN-Strecken implementieren. Hinzu kommen optionale Module für das Rate Shaping, Client Authentication, Caching, ein IP-V6-Gateway und eine Web-Application-Firewall.
Besonderheiten
-- Schneller Balancer für hohes Lastaufkommen;
- Balancing auch über WAN-Strecken mit Failover-Funktionen möglich.
- Unterschiedliche Bearbeitungsstufe durch den Wechsel zwischen ASIC und Software.
Citrix gliedert in Zonen und Farmen
Beim Server-based-Computing, wie es beispielsweise mit Citrix und dessen "Presentation Server" möglich ist, wird das Balancing zur Pflicht. Dies schon deshalb, da hier die zentralen Server eine weitaus höhere Auslastung erreichen, als dies beim traditionellen Client-Server-Computing der Fall ist. Das Konzept von Citrix unterscheidet verschiedene Zonen, die zu einer Farm zusammengefasst sind. Der Data Collector einer Farm sammelt und verwaltet die jeweiligen Lastinformationen aller Mitglieder. Eine Zone wiederum stellt eine Gruppe an Server-Systemen dar, die gemeinsam einen Dienst (die Applikationen) bereitstellen.
Der Load Manager wählt den geeigneten Server aus
Ein Benutzer kann optional immer einer (bevorzugten) Zone zugewiesen werden, nicht jedoch einem dedizierten Rechner. Beim Aufbau einer Sitzung erhält der Benutzer durch einen Load Manager den Server zugewiesen, der zu diesem Zeitpunkt die geringste Auslastung aufweist. Diese Verbindung gilt bis zum Ende der Session. Da die Phase des Session-Aufbaus im Vergleich zur lokal gestarteten Windows-Anwendung länger dauert, können davor wieder Balancer geschaltet werden. Die Entscheidung über den zugewiesenen Server wird damit durch zwei Instanzen bestimmt: den Administrator, der im Vorfeld die Zone festlegt, sowie den Load Manager, der zum Anmeldzeitpunkt einen Server der Zone auswählt.
Da eine Benutzer-Session den ganzen Arbeitstag dauern kann, ist dieses Vorgehen natürlich nicht sehr flexibel. Andererseits würde die Übertragung einer vollständigen Benutzer-Session auf einen anderen Server einen kaum zu vertretenden Aufwand bedeuten. Dennoch ist die Lastverteilung des Presentation Server damit nur unzureichend gelöst. Um sie zu optimieren, dreht man an den Zeitscheiben, die für die Prozesse zur Verfügung stehen. So offeriert etwa die Firma Appsense einen Performance Manager für Citrix-Umgebungen, der für eine Benutzer-Session deren CPU-Anteil begrenzt. Dadurch werden all jene Prozesse gebremst, die auf Kosten anderer übermäßige CPU-Anteile konsumieren.
Citrix erlaubt prinzipiell eine beliebige Verteilung der Applikations- und Daten-Server im WAN. Dennoch empfiehlt der Hersteller, bei Engpässen den Applikations-Server unter Nutzung von schnellen LAN-Verbindungen möglichst nahe beim Daten-Server zu platzieren, um die Wege zwischen beiden effizient zu gestalten. Die Verwaltung erfolgt immer Farm- und nicht Server-bezogen.
Daneben liefert Citrix mit dem Netscaler Switch seit letztem Jahr auch eine Appliance zur Beschleunigung von Web-Anwendungen. Diese umfasst einen Balancer zur Verteilung der Web-Anfragen auf die Server, einen Reverse Proxy zum Caching der Inhalte, deren Kompression, eine SSL-Verschlüsselung sowie weitere Unterstützung für das Layer-4- bis Layer-7-Traffic-Management.
Besonderheiten
-- Balancer für Server-based-Computing;
- Session-Übergabe durch Roaming-Funktionen.
- Nur im Kontext des Presentation Server anwendbar.
Microsoft bietet zwei Verfahren
Microsoft offeriert zwei unterschiedliche Konzepte zur Lastverteilung. Den "Cluster Server" und den "Network Load Balancer". Beim Cluster Server operieren zwei identische Applikationen parallel und teilen sich einen gemeinsamen Speicher, der via NAS oder SAN angebunden werden kann. Die beteiligten Server erhalten eine gemeinsame IP-Adresse. Cluster Server wird hauptsächlich dazu verwendet, Ausfallsicherheit zu gewährleisten.
Der Microsoft Network Load Balancer (NLB) ist als Dienst in den Server-Betriebsystemen ab Windows 2000 implementiert und läuft damit parallel zu anderen Anwendungen, er wird also den Servern nicht vorgeschaltet. Diese führen alle den NLB-Dienst aus. Die beteiligten Rechner können unterschiedlich sein und benötigen lediglich einen gemeinsamen Netzzugang. Empfohlen werden zwei unabhängige Netzwerkkarten: Eine für den Austausch der Statusinformation, die zweite für die Zugänge der Clients und des Heartbeats. Bei Änderungen an der Gesamtkonfiguration, und das schließt auch die Initialisierung der Systeme beim Start ein, handeln diese untereinander die Verteillogik und damit die prozentuale Verteilung der Last aus. Die Werte werden aus den Leistungsdaten der angeschlossenen Rechner gewonnen. Damit ist das Verhalten relativ starr und entspricht einer statischen Verteilung der Last.
Erst bei Änderungen an der Gesamtkonfiguration (etwa bei Ausfall, Entnahme oder Hinzufügen eines Systems) wird die zuzuweisende Last neu verhandelt. Ferner kann über WMI-Scripting die Lasterverteilung automatisch geändert werden. Neben diesen Lastfaktoren wird die Verteilung unter anderem auch anhand der Absendeadresse und des Absende-Ports des Client-Pakets vorgenommen. Ein Session-Transfer beim Ausfall eines Systems wird nicht vorgenommen.
Das Session-Handling wird durch Tabellen (Affinity Masks) verwaltet. Der NLB unterstützt sowohl Single Affinity, wobei alle Anfragen eines Clients (basierend auf seiner IP) immer vom selben Server bearbeitet werden, als auch den Modus "No Affinity". Dieser kann aufeinander folgende Anfragen eines Clients auf beliebige Server verteilen, was allerdings nur für reine Auskunftssysteme sinnvoll ist, da sich ein Session-Handling damit nicht erzielen lässt. Für Microsofts Firewall (Internet Security and Acceleration Server = ISA) bietet der Hersteller Rainfinity mit "Rainwall" und "Rainconnect" zwei Produkte, die mit dem ISA-Server kombiniert werden und dort eine Lastverteilung vornehmen können. Die Verwaltung des NLB erfolgt im Kontext des jeweiligen Gast-Betriebssystems.
Besonderheiten
-- Preisgünstig, da in Windows integriert;
- sehr einfache Inbetriebnahme.
- Nur begrenzter Funktionsumfang;
- auf Windows-Systeme beschränkt.
Zeus thront auf Web-Servern
Das Freiburger Unternehmen Pyramid liefert eine Appliance namens "Zeus ZXTM" (Zeus Extensible Traffic Manager). Sie besteht aus einer eigenen Hardware, einem gehärteten Linux und der Load-Balancer-Software ZXTM des Unternehmens Zeus aus Cambridge.
Das Produkt umfasst die Kernaufgaben des Load Balancing, Traffic-Managements sowie weitere Sicherheitsfunktionen. Der Balancer operiert auf den Netzebenen drei bis sieben. Dazu gehören alle gängigen UDP- und TCP-Protokolle mit http, SMTP, POP, Imap, SSL, SIP, Radius oder Telnet. Bezüglich der Verteilung unterstützt Zeus die Verfahren nach Session pro Server, Durchsatz des Servers, Benutzeranzahl oder Round Robin. Ferner kann nach IP-Adresse des Web-Benutzers, TCP-Port, Diensten oder dem Content verteilt werden. Zur Realisierung der Session Persistence für SSL-Sessions werden mehrere Techniken angeboten.
Zu den weiteren Funktionen gehören eine Verschlüsselung und Komprimierung des Datenstroms mit Bandbreitenkontrolle und automatischer Zuweisung von Netzbandbreite an Dienste oder Protokolle. Das Produkt übernimmt auch die Verwaltung von Sicherheitszertifikaten sowie das SSL-Offloading. Integriert ist ferner die Erkennung von DoS-Attacken.
Angewandt werden die Appliances vor allem für die Web-Server von Apache und Microsoft. Die Verwaltung erfolgt zentral über ein Web-GUI, auch eine Skriptsprache zur Programmierung gehört dazu. Durch SNMP-Traps lässt sich das Toolkit in gängige System-Management-Suites einbinden.
Besonderheiten
-- Günstige Appliance;
- Zusatzfunktionen für Sicherheit.
- Relativ begrenzter Umfang;
- nur wenige Kriterien für Lastverteilung.
Die fünf Load-Balancing-Lösungen in der Übersicht
Produktname Failover Cluster (MSCS) ZXTM BIG-IP Traffic Manager Citrix Netscaler Radware Cluster Server und NLB Application Switch App Director
Hersteller Microsoft Pyramid / Zeus Technology F5 Networks Citrix Radware
Preis Teil von Windows Server ab 12750 Euro ab 16995 Euro ab 25000 Dollar auf Anfrage Enterprise und Datacenter Edition
Architektur
Als SW-Dienst unter dem Betriebssystem ja ja (Linux) - ja (Netscaler-OS) ja (Appliance-OS)
Als Add-on für bestehende Router / nein nein - nein - Switches / ....
Als HW-Appliance Nein ja ja (TMOS) ja ja
Balancing-Verfahren
Round-Robin (zyklisch) - ja ja ja ja
Nach User- und Session-Zahl - ja ja ja ja
Nach Download-Traffic - ja ja ja ja
Nach Absender-IP-Adressen - ja ja ja ja
Nach Dienst: HTTP / FTP / SMTP / Jeder Dienst, der als Res- HTTP, HTTPS, POP3, SMTP, alle HTTP / FTP / SMTP / alle IP-Anwendungen DHCP / DNS / ... source in einer Cluster-Grup- FTP, DNS, SSL, SIP, RADIUS, DHCP/ DNS pe läuft, kann auf die einzel- Telnet ? erweiterbar durch nen Nodes verteilt werden. Trafficscript auf viele TCP/UDP-Protokolle
Layer 4 / Layer 7 / .... - Layer 7 Layer 4 / Layer 7 Layer 4 / Layer 7 Layer 2 bis Layer 7
Weitere Statisches Loadbalancing Skriptsprache Trafficscript, Fastest, Predictive,Obser- URL/ Domain/ nach "Proximity", durch Verteilen der Resour- XML-Processing, SSL ved, Ratio, Dynamic Ratio, Source-IP/ nach Antwortzeiten cen auf die Cluster-Nodes Decryption/(Re)encryption Priority Groups, iRules Destination-IP
Weitere Funktionen
Bandbreiten-Management - ja ja nein ja
Komprimierung ja ja ja ja ja
Verschlüsselung IPSec ja ja ja ja
Fehlertoleranz und Failover des Balancer - ja ja ja ja
Lastermittlung der Server: SNMP-Traps/ Performance-Monitor SNMP, Scripting, Latenz- ja (SNMP, Skripts, API) ja ja Scripting / Sonstiges messung
Session-Transfer möglich Session Reconnect bei ja ja (stateful Failover) ja ja einem Failover durch den Client
Hier lesen Sie ?
? welche Aufgaben Load Balancer übernehmen;
? nach welchen Kriterien sie Last verteilen;
? die Bedeutung des Session-Handlings im Balancing;
? wie die Produkte neue Disziplinen aufnehmen.
Die Produkte
Auf den zwei Folgeseiten finden Sie eine Beschreibung fünf ausgewählter Balancing-Lösungen: n Microsoft Cluster Server und Network Load Balancer;
? Citrix Load Manager und Netscaler;
? Radware App Director;
? Zeus XTM;
? F5 Networks BIG-IP.
Ob Web- oder File-Server, Datenbanken oder ERP-Instanzen, jedes dieser IT-Systeme ist einer mehr oder weniger großen Belastung ausgesetzt. Um diese Schwankungen zu bewältigen, wird die ihnen abgeforderte Last auf mehrere Server im Cluster-Betrieb verteilt. Die hierfür eingesetzten Load Balancer spielen ihre Vorteile vor allem in Bereichen aus, die ein sehr dynamisches Verhalten voraussetzen. Selbst Netzwerkstrecken, VPN-Tunnels, VoIP-, DHCP- oder DNS-Dienste - alles wird dem Balancing unterworfen. Meist sind die Balancer der jeweiligen Komponente vorgeschaltet. Sie fangen die Aufträge ab, um sie dann statisch oder dynamisch nach einstellbaren Kriterien auf die verfügbaren Systeme zu verteilen.
Auswahl des Servers
Ausgehend von der Verarbeitungskette, stellt der im Benutzergerät angeforderte DNS-Dienst die zentrale Anlaufstelle für das Load Balancing dar. Durch DNS erfolgt die Namensauflösung in die IP-Adresse des gesuchten Server-Dienstes. Die Auswahl des jeweiligen Servers, der die Anfrage erhält, kann unterschiedlich implementiert sein. Beim Round-Robin-Verfahren, einer sehr einfachen Form der Lastverteilung, werden die Aufträge der Reihe nach zu den Servern geschleust. Die Verteilung der Anfragen erfolgt numerisch gleich und ohne Rückschluss auf die aktuelle Last der Server. Für einfache Zugriffe, etwa auf ein Web-Auskunftssystem, mag dies durchaus genügen. Die Lastverteilung mit DNS ist einfach zu implementieren und erfordert keine separate Hardware oder Software.
Einen Schritt weiter geht ein als Load Partitioning bezeichnetes Verfahren. Hierbei wird im Vorfeld durch zusätzliche Kriterien festgelegt, wie die Last zu verteilen ist. Dabei ordnet man jedem Server einen prozentualen Wert der Gesamtlast zu. Als Grundlage hierfür kann ein beliebiger, aber dennoch fester Schlüssel herangezogen werden, der sich beispielsweise aus dem Leistungsvermögen des jeweiligen Servers ergibt. Ideal ist dieses Vorgehen sicher nicht. Denn erst wenn der Balancer Bescheid weiß über die tatsächliche Auslastung eines Servers, kann er den mit der geringsten Last auswählen.
Die Auslastung wird definiert über mehrere Lastkriterien, die unterschiedlich gewichtet sind. Dies kann die Antwortzeit für eine Anfrage sein, die Anzahl der Benutzer oder Sessions, die Auslastung der Server-Hardware wie CPU, Festplatten oder I/O-Baugruppen und schließlich die Intensität des Netzverkehrs. Darüber hinaus gibt es ein ganzes Spektrum an Bestimmungsmethoden: Sie reichen von einer eigenen und unabhängigen Verdrahtung mit serieller Leitung über SNMP-Traps bis hin zu periodischen Abfragen durch Skripte.
Trennung nach Diensten ?
Einen weiteren Balancing-Ansatz stellt die Verteilung der Anfragen nach den angeforderten Inhalten dar. Dies kann beispielsweise anhand von URL-Adressen oder den dazu notwendigen Diensten geschehen. Eine Trennung nach Diensten liegt auch vor, wenn sich die Verteilung an Protokollen wie FTP, http, HTTPS, E-Mail (IMAP, POP, SNMP) oder WAP orientiert. Die Aufsplittung der Last kann dabei relativ einfach unter Berücksichtigung des Empfangs-Ports oder des Protokolls auch durch NAT-Router mit Port-Forwarding vorgenommen werden. Dazu muss ein Balancer natürlich mehr an Logik mitbringen, um die Anforderungen analysieren zu können.
? und Inhalten
Andere Kriterien zur Lastverteilung sind die Unterscheidung nach Absender-IP-Adresse, nach Sessionzahl, nach der Menge des Netzwerkverkehrs, nach Download-Volumen oder I/O-Last. Häufig wird auch eine Trennung des Web-Content in die Bildanteile (GIF, JPG) und Textanteile (HTML) vorgenommen. Ebenso ist eine Separierung in statische Web-Inhalte und dynamisch generierte Informationen aus Datenbanken möglich.
Als Entscheidungsgrundlage, an welchen Server der Balancer eine Anfrage weiterreicht, sind also alle Informationen heranzuziehen, die er erhalten und auswerten kann. Ähnlich wie bei Firewalls kommt es darauf an, welche der sieben Schichten des ISO/OSI-Modells unterstützt werden. Ein Balancer, der auf einem Layer-2-Switch implementiert ist, kann folglich seine Entscheidung auch nur an den Inhalten der Ebene 2 ausrichten. Werden die oberen Schichten ebenfalls unterstützt, so stehen weitaus mehr Informationen zur Verfügung. Balancer, die auf den oberen Schichten operieren, sind flexibler und in der Lage, die ankommenden Pakete zu entpacken, um anhand der Inhalte die Empfänger zu adressieren. Andererseits sind die reinen Port-Forwarder, die lediglich auf der vierten Schicht arbeiten, sehr schnell und stellen keine hohen Ansprüche an die Leistungsfähigkeit der Hardware.
Der Markt bietet reine Hardware-Implementierungen mit Asics, reine Softwarelösungen und natürlich den Verbund beider in Form von Appliances. Da die Balancer in die Zugriffsstrecke zwischen Client und Server eingebunden sind, werden sie selbst zum zentralen Zugriffsknoten. Um einen Single-Point-of-Failure zu vermeiden, sind sie in der Regel redundant als Paar ausgelegt. Daneben existieren aber auch Verfahren, bei denen der Balancer nicht separat dem Server vorgeschaltet ist, sondern als Dienst parallel auf den Ziel-Servern vorgehalten wird.
Session-Handling
Zu den wichtigen Anforderungen an Balancer gehört das Session-Handling. Eine Session beschreibt einen zusammengehörigen Verarbeitungsblock, der nicht beliebig zerpflückt werden kann, da sonst ein unverhältnismäßiger Overhead generiert würde. Um Sessions beispielsweise bei einem Hardwareausfall nicht abrupt enden zu lassen, müssen sie auf einem anderen System weitergeführt werden. Sessions sind nach der ISO/OSI-Definition auf Schicht fünf angesiedelt, weshalb eine Session-Verwaltung auch nur von den Systemen übernommen werden kann, die die oberen Schichten auswerten.
Für die Umsetzung der als Session Persistence bezeichneten Funktion gibt es mehrere Wege: Es lassen sich die IP-Adresse des Web-Nutzers, Cookies, Session-IDs oder all diejenigen Werte heranziehen, die eine einmal begonnene Verbindung eindeutig kennzeichnen. Ein Session-Transfer ist jedoch nur dann möglich, wenn die Applikationsprogramme die Session-Daten nicht lokal im eigenen Datenbereich vorhalten, sondern in einem globalen Adressraum hinterlegen. Als globaler Adressraum gilt natürlich auch eine zentrale Datenbank, auf die alle beteiligten Server Zugriff haben.
Alternativ können die Session-Daten bei jedem http-Roundtrip etwa über URLs ausgetauscht werden. Dann sollte es sich aber unbedingt um eine abgesicherte Verbindung wie https handeln. In die gleiche Richtung zielt die Session-Verwaltung über XML-Dokumente. Auch hier werden die Session-Daten Client-seitig vorgehalten und dem Server bei jedem Aufruf mitgeteilt.
Balancer in fremden Revieren
Sofern ein Balancer auf den oberen Protokollschichten operiert, lassen sich die Analyseoptionen für die Datenpakete deutlich ausweiten. So mancher Hersteller nutzt inzwischen diese Möglichkeit und integriert Funktionen in sein Produkt, die im Kern nichts mehr mit Balancing zu tun haben. Damit mutieren die Systeme in Richtung Traffic- oder Bandbreiten-Management. Dabei verwenden sie die aus den Datenpaketen gewonnenen Informationen, um bestimmte Verbindungen zu beschleunigen, zu bremsen oder den Datenverkehr zu chiffrieren. Ferner finden sich Features, wie sie aus Security-Produkten bekannt sind, beispielsweise für Intrusion Detection oder Intrusion Prevention samt der Verhinderung von DoS-Angriffen.
Integrierte Security
Beim SSL-Offloading fungiert der Balancer als Endpunkt für eine gesicherte SSL-Verbindung. Er übernimmt dabei das Ver- und Entschlüsseln der Datenpakete. Doch das Entpacken und die Analyse der Pakete kostet Zeit und verlangt entweder nach einer leistungsfähigen Hardware, oder diese Funktionen werden von vornherein in Asics gegossen. Einen weiteren Weg der Lastoptimierung stellt das Reverse Caching von Web-Inhalten dar. Hierbei werden aus dem Internet angefragte Seiten in einem dem Web-Server vorgeschalteten Zwischenpuffer - dem Reverse Cache - abgelegt. Das beschränkt sich also auf ausgehenden Web-Traffic, entlastet allerdings die nachgeschaltete Web-Server-Farm. (ue)