Client-Server-Anwendungen verteilen
Der richtige Weg
28. März 2012, 7:00 Uhr |
Ekkehard Gümbel/jos, Regionaldirektor Zentral- und Nordeuropa/Mittlerer Osten bei Kemp Technologies.
Ist eine Anwendung "down", so ist das ärgerlich und oft auch teuer. Dies gilt für E-Mail und Messaging genauso wie für Datenbanken, ERP-Anwendungen, Terminal-Server oder Spezialanwendungen, etwa in der Produktion oder dem Gesundheitswesen. Und natürlich für interne und externe Websites aller Art, nicht nur im E-Commerce.
Bei der Bereitstellung solcher Anwendungen geht es oft um Verfügbarkeit, manchmal um Skalierbarkeit, häufig um beides. Lösungen dafür gibt es verschiedene, und in aller Regel basieren sie auf dem Funktionsprinzip, Anwendungsinhalte auf mehrere Server zu verteilen und die Zugriffe der Clients ebenfalls. Der erste Teil dieses Prinzips ist naturgemäß anwendungsabhängig zu lösen. Stichworte dazu sind: periodisches Kopieren, Online-Synchronisation, Frontend/Backend-Aufteilung etc.
Der zweite Teil des Funktionsprinzips wirkt auf der Netzwerkebene durch Einsatz eines Load Balancers. Dabei verbindet sich der Client nicht mehr direkt mit einem Server, sondern – ohne es zu „wissen“ – mit einem Vorschaltgerät. Auf diesem ist für die jeweilige Anwendung ein virtueller Service bereitgestellt. In der Regel ist dies eine virtuelle IP (VIP) mit einem zugehörigen TCP- oder UDP-Port (zum Beispiel TCP 80 für die meisten Web-Anwendungen). Jede Anfrage geht dann intelligent zu den eigentlichen Servern weiter.
Das Vorschaltgerät, der „Server Load Balancer“, ist für drei Hauptaufgaben zuständig:
Aufrechterhaltung von logischen Verbindungen über mehrere Netzwerk-Connections hinweg (Session Persistence),
Mengenmäßige Aufteilung (Scheduling) und
Überwachung der Server in Hinblick auf Ausfälle (Health Checking).
Für jede dieser Aufgaben sind unterschiedliche Strategien und Techniken anwendbar. Ein hochwertiger Load Balancer zeichnet sich durch eine breite Auswahl an intelligenten und flexiblen Optionen aus, die am besten auf der Anwendungsebene (Layer 7) arbeiten sollten. Ein Beispiel: Um sicherzustellen, dass eine Web-Anwendung wirklich noch funktioniert, reicht es nicht, sich mit TCP-Port 80 zu verbinden. Es ist mindestens der Status-Code einer sinnvoll gewählten Testseite zu prüfen, möglicherweise sogar deren Inhalt.
Neben ihren Kernaufgaben übernehmen Load Balancer heute auch weitere Funktionen wie SSL-Beschleunigung, HTTP-Funktionen wie Caching, Kompression und Content Routing oder Intrusion Prevention (IPS). Im Fachjargon hat sich daher der Begriff Application Delivery Controller (kurz ADC) etabliert.
Da in aller Regel auch der Load Balancer/ADC kein Single Point of Failure sein darf, arbeitet er fast immer paarweise, am besten eingebettet in eine redundante Switch-Infrastruktur. Der eingebaute Cluster-Mechanismus des Load Balancers sorgt dafür, dass jeder virtuelle Service zu jedem Zeitpunkt auf einem der Load Balancer aktiv ist. Er sollte allerdings zusätzlich das „stateful“ Failover unterstützen: Beim Ausfall eines Load Balancers, das heißt beim Wechsel des virtuellen Services auf den zweiten Load Balancer, sollen die Benutzer-Sessions ungestört erhalten bleiben.
Verteilung über mehrere Standorte
Die beschriebene Technik beruht auf einer Gruppe lokaler Server, und alle Anfragen laufen durch den Load Balancer als zentralem Verteiler. Server Load Balancing schützt somit zuverlässig vor dem Ausfall einzelner Server und ermöglicht die intelligente und dynamische Verteilung der Last auf mehrere Systeme. Was passiert jedoch, wenn die Last über mehrere Standorte verteilt werden soll? Oder wenn ein ganzer Rechenzentrumsstandort ausfällt, etwa durch Stromausfall, Brand, oder Wegfall der Netzanbindung?
Soll das System einen solchen Fall abdecken, so ist zwischen zwei Szenarien zu unterscheiden:
der lokalen Dopplung (also zwei RZ-„Module“, die räumlich kaum getrennt und zum Beispiel auf Ethernet-Ebene querverbunden sind) und
der geografischen Verteilung (über unterschiedliche Städte oder gar Länder).
Für die lokale Dopplung lautet die gute Nachricht: Server Load Balancing ist auch dort vollständig anwendbar, und es entsteht kein Single Point of Failure. Bild 1 illustriert die Funktionsweise: Die Benutzeranfragen gelangen über das als verfügbar anzunehmende Client-Netz zum aktiven virtuellen Service auf einem der Load Balancer. Dabei ist meist ein „Hauptstandort“ als präferiert festgelegt. Dieser aktive Load Balancer verteilt die Anfragen dann gemäß der gewünschten Regeln, zum Beispiel vorzugsweise auf die Server an seinem Standort (active/passive) oder aber auf alle Server an beiden Standorten (active/active).
Komplettausfall keine Katastrophe
Bei Komplettausfall des Hauptstandorts – ebenso wie beim Ausfall einer kritischen Komponente wie etwa des dortigen Load Balancers oder eines angebundenen Switches – übernimmt dann der zweite Load Balancer am anderen Standort und verteilt auf Basis derselben Regeln. Dieses Setup lässt sich noch weiter perfektionieren, etwa durch eine redundante Switch-Infrastruktur an jedem Standort in Verbindung mit Failover Trunking am Load Balancer. Aber bereits in der dargestellten Variante sind die beiden Ziele Ausfallsicherheit und intelligente Verteilung erreicht.
Geografische und globale Verteilung
Anders sieht es aus, wenn die RZ-Standorte weiter voneinander entfernt liegen. In diesem Fall kann Server Load Balancing nicht mehr funktionieren: zum einen aufgrund der hohen Latenzen, zum anderen, weil das Funktionsprinzip, jede einzelne Client-Anfrage über einen zentralen Server laufen zu lassen (etwa in Frankfurt) und dann an einen anderen Standort (etwa New York) weiterzuleiten, keinen Sinn ergeben würde. Dann ist eine andere Lösung gefragt, das so genannte Global Server Load Balancing (GSLB).
GSLB ermöglicht es, Clients auf RZ-Standorte zuzuordnen, und zwar mit einem einfachen Trick: Will sich beispielsweise ein Benutzer per Outlook oder OWA mit seinem Exchange-Server verbinden oder ein Web-Benutzer mit einem Online-Shop, so wird naturgemäß zunächst ein DNS-Lookup des gewünschten Server-Namens durchgeführt. An dieser Stelle kommt jedoch nicht immer die gleiche IP-Adresse zurück, sondern es erfolgt eine Auswahl aus mehreren hinterlegten IPs (sprich: Standorten), und zwar wiederum regelbasierend.
Beispiele sind:
„Wähle immer Frankfurt. Nur wenn Frankfurt down ist, dann wähle New York!“
„Wähle New York für US-Kunden, ansonsten immer Frankfurt!“
„Wähle Frankfurt, New York, oder Singapur – je nachdem, welcher Standort am nächsten zum Kunden liegt!“
„Wähle Frankfurt, New York, oder Singapur – je nachdem welcher Standort am wenigsten ausgelastet ist!“
Die Funktion beschränkt sich nicht auf reines Failover, sondern es lassen sich auch Dinge wie active/active-Verteilung über mehr als zwei Standorte realisieren oder eine Geo-Verteilung nach verschiedenen Kriterien.
Dennoch hat GSLB seine Grenzen, es kann lokales Server Load Balancing nicht ersetzen. Aufgrund des zugrundeliegenden Prinzips sind die Umschaltzeiten bei einem Ausfall hoch (DNS-Caching), und ein hochwertiges Arbeiten auf Anwendungsebene ist ebenfalls nicht abbildbar. Der typische Einsatzfall ist die Kombination beider Welten: GSLB für die Verteilung über Standorte hinweg, Server Load Balancing innerhalb jedes Standorts (Bild 2).
Server Load Balancing und GSLB sind erprobte Techniken, die heute in alle Bereiche der Netzwerkinfrastruktur Einzug gehalten haben. Die traditionell eher hohen Preisstrukturen sind mittlerweile aufgebrochen und hochwertige Produkte erschwinglich. Dies verstärkt den Trend, solche Produkte zu verwenden. Diese setzen zudem auf einfache, Web-basierende Bedienung anstatt auf komplizierte Programmierung. Alternative Ansätze haben in Teilbereichen ihre Daseinsberechtigung, so etwa die plattformbasierende Verfügbarkeit und Skalierung durch Virtualisierung oder freie Low-End-Produkte wie Microsofts Network Load Balancer (NLB). Diese bergen allerdings erhebliche Nachteile etwa in der applikationsbezogenen Steuerbarkeit und Fehlererkennung. So würde zum Beispiel ein „Error 500“ eines Webservers von keiner dieser Lösungen abgefangen. Daher empfehlen selbst VMware oder Microsoft den Einsatz eines „echten“ Load Balancers, wenn es um die zuverlässige Bereitstellung von Anwendungen geht.
Sorgsame Produktwahl
Bei der Produktauswahl ist sowohl auf Leistung und Vielfalt in den Kernfunktionen zu achten wie auch auf Flexibilität und erweiterte Funktionen, um für Sonderfälle gewappnet zu sein. Unbedingt zu empfehlen ist in jedem Fall, sich nicht nur auf Gedrucktes zu verlassen, sondern selbst zu auszuprobieren. Die Unterschiede werden selbst dem Einsteiger schnell deutlich.
Bild 1. Server Load Balancing kann lokal arbeiten oder auf zwei benachbarte Standorte aufgeteilt sein. Für die genaue Topologie sind verschiedene Varianten möglich.
Lesen Sie mehr zum Thema
