Auf dem dynamischen, anwendungsorientierten Markt von heute stehen Unternehmen zunehmend unter Druck, ihren Kunden die Informationen, Dienste und Erfahrungen zu liefern, die sie erwarten – und zwar schnell, zuverlässig und sicher. Wichtige Netzwerk- und Anwendungsfunktionen wie Lastausgleich, Verschlüsselung, Beschleunigung und Sicherheit können über Application Delivery Controller (ADC) bereitgestellt werden. Dabei handelt es sich um physische oder virtuelle Appliances, die als Proxys für physische Server fungieren. Angesichts der explosionsartigen Zunahme an Anwendungen und der Anforderungen, die der strenge Zyklus aus kontinuierlicher Integration und kontinuierlicher Bereitstellung (CI/CD) an Unternehmen stellt, überrascht es nicht, dass der Markt für ADCs Prognosen zufolge bis 2020 ein Volumen von 2,9 Milliarden US-Dollar pro Jahr erreichen wird.1
Doch bevor wir in die Zukunft blicken, schauen wir uns an, wie wir hierher gekommen sind. Netzwerkbasierter Lastausgleich ist die wesentliche Grundlage für den Betrieb von ADCs. Mitte der 1990er Jahre unterstützten die ersten Hardwaregeräte zum Lastenausgleich Unternehmen bei der Skalierung ihrer Anwendungen, indem sie die Arbeitslast auf Server und Netzwerke verteilten. Diese ersten Geräte waren anwendungsneutral und befanden sich außerhalb der eigentlichen Anwendungsserver, was bedeutet, dass sie mithilfe einfacher Netzwerktechniken einen Lastausgleich durchführen konnten. Im Wesentlichen würden diese Geräte der Außenwelt eine „virtuelle IP-Adresse“ präsentieren und beim Verbindungsversuch der Benutzer die Verbindung mithilfe einer bidirektionalen Netzwerkadressübersetzung (Network Address Translation, NAT) an den am besten geeigneten realen Server weiterleiten.
Mit dem Aufkommen der Virtualisierung und des Cloud-Computing kam jedoch eine neue Generation von ADCs zur Lastverteilung auf den Markt, die als softwarebasierte virtuelle Editionen auf Hypervisoren laufen sollten. Heutzutage können virtuelle Appliances Anwendungsdienste mit der gleichen Bandbreite an Funktionen bereitstellen wie solche, die auf speziell entwickelter Hardware ausgeführt werden. Darüber hinaus beseitigen diese virtuellen Editionen einen Großteil der Komplexität, die mit der Verschiebung von Anwendungsdiensten zwischen virtuellen, Cloud- und Hybridumgebungen verbunden ist, und ermöglichen Unternehmen so die schnelle und einfache Einrichtung von Anwendungsdiensten in privaten oder öffentlichen Cloudumgebungen.
Der neuste Trend im Rechenzentrum ist die Containerisierung, eine Methode der Anwendungsvirtualisierung, die bei der Bereitstellung und Ausführung verteilter Anwendungen hilft. Der Prozess isoliert Anwendungen und speichert sie in klar abgegrenzten Speicherbereichen auf einem gemeinsam genutzten Betriebssystem. Dadurch ist die Entwicklung und Bereitstellung einer Anwendung nicht nur einfacher als beim Erstellen einer virtuellen Appliance, sondern auch schneller. Aufgrund der dramatischen Verbesserungen bei Portabilität und Leistung könnte die Containerisierung Unternehmen mehr Skalierbarkeit und Agilität bieten. Containerarchitekturen könnten Unternehmen in Zukunft auch dabei helfen, die Vorteile unterschiedlicher Cloud-Umgebungen besser zu nutzen.
Die heutigen ADCs haben sich aus den ersten Load Balancern durch den Service-Virtualisierungsprozess entwickelt. Und jetzt können ADCs mit reinen Software-Editionen nicht nur die Verfügbarkeit verbessern, sondern Unternehmen auch dabei helfen, die skalierbaren, leistungsstarken und sicheren Anwendungen bereitzustellen, die ihr Unternehmen benötigt. Letztendlich wären all diese virtualisierten Anwendungsdienste, gemeinsam genutzten Infrastrukturbereitstellungen und intelligenten Routing-Funktionen ohne die solide Grundlage der Lastausgleichstechnologie nicht möglich.
Um zu verstehen, wie Unternehmen die komplexen Herausforderungen des sich dynamisch entwickelnden Marktes besser bewältigen können, untersuchen wir die Grundlagen der Anwendungsbereitstellung: Lastausgleich 101.
Bevor wir beginnen, wollen wir die grundlegende Terminologie des Lastenausgleichs wiederholen. Dies wäre einfacher, wenn alle dasselbe Vokabular verwenden würden. Leider scheint jeder Anbieter von Lastausgleichsgeräten (und damit auch von ADCs) eine andere Terminologie zu verwenden. Mit ein paar Erklärungen können wir jedoch die Verwirrung beseitigen.
Die meisten ADCs zum Lastausgleich verwenden die Konzepte eines Knotens, Hosts, Mitglieds oder Servers. Einige haben alle vier, aber sie bedeuten unterschiedliche Dinge. Es gibt zwei grundlegende Konzepte, die diese Begriffe zum Ausdruck bringen sollen. Ein Konzept – normalerweise Knoten oder Server genannt – ist die Idee des physischen oder virtuellen Servers selbst, der Datenverkehr vom ADC empfängt. Dies ist gleichbedeutend mit der IP-Adresse des physischen Servers und wäre in Ermangelung eines Lastenausgleichs die IP-Adresse, in die der Servername (z. B. www.example.com) aufgelöst würde. Im weiteren Verlauf dieses Dokuments bezeichnen wir dieses Konzept als „Host“.
Der zweite Begriff wird durch den Begriff „Member“ (von manchen Herstellern leider auch Node genannt) ausgedrückt. Ein Mitglied ist normalerweise etwas genauer definiert als ein Host, da es den TCP-Port der eigentlichen Anwendung umfasst, die den Datenverkehr empfängt. Beispielsweise kann ein Host mit dem Namen www.example.com die Adresse 172.16.1.10 ergeben, die den Host darstellt, und eine Anwendung (einen Webserver) auf TCP-Port 80 ausführen, wodurch die Mitgliedsadresse 172.16.1.10:80 wird. Einfach ausgedrückt umfasst das Mitglied die Definition des Anwendungsports sowie die IP-Adresse des physischen/virtuellen Servers. Im weiteren Verlauf dieses Dokuments bezeichnen wir dies als „Dienst“.
Warum diese ganze Komplexität? Denn durch die Unterscheidung zwischen einem Server und den darauf laufenden Anwendungsdiensten kann der Load Balancer individuell mit den Anwendungen interagieren und nicht mit der zugrunde liegenden Hardware oder dem Hypervisor in einem Rechenzentrum oder in der Cloud. Ein Host (172.16.1.10) kann über mehr als einen Dienst verfügen (HTTP, FTP, DNS usw.). Durch die eindeutige Definition jeder Anwendung (z. B. 172.16.1.10:80, 172.16.1.10:21 und 172.16.1.10:53) kann der ADC eine eindeutige Lastverteilung und Integritätsüberwachung (ein Konzept, auf das wir später noch eingehen) basierend auf den Diensten statt auf dem Host anwenden.
Bedenken Sie, dass die meisten auf Lastausgleich basierenden Technologien einen Begriff zur Darstellung des Hosts oder physischen Servers und einen anderen zur Darstellung der darauf verfügbaren Dienste verwenden – in diesem Fall einfach „Host“ und „Dienste“.
Durch Lastenausgleich können Unternehmen eingehenden Anwendungsverkehr auf mehrere Back-End-Ziele verteilen, einschließlich Bereitstellungen in öffentlichen oder privaten Clouds. Daher ist es notwendig, das Konzept einer Sammlung von Back-End-Zielen zu haben. Cluster, wie wir sie nennen (sie werden auch Pools oder Farmen genannt), sind Sammlungen ähnlicher Dienste, die auf einer beliebigen Anzahl von Hosts verfügbar sind. Beispielsweise würden alle Dienste, die die Unternehmenswebseite anbieten, in einem Cluster namens „Unternehmenswebseite“ gesammelt und alle Dienste, die E-Commerce-Dienste anbieten, würden in einem Cluster namens „E-Commerce“ gesammelt.
Ein virtueller Server ist ein Proxy des tatsächlichen Servers (physisch, virtuell oder Container). In Kombination mit einer virtuellen IP-Adresse ist dies der Anwendungsendpunkt, der der Außenwelt präsentiert wird.
Mit dem Verständnis dieser Begriffe beherrschen wir die Grundlagen des Lastausgleichs. Der Lastausgleichs-ADC präsentiert der Außenwelt virtuelle Server. Jeder virtuelle Server verweist auf einen Cluster von Diensten, die auf einem oder mehreren physischen Hosts liegen.
Obwohl Abbildung 2 möglicherweise nicht repräsentativ für eine reale Bereitstellung ist, bietet sie die grundlegende Struktur für die Fortsetzung einer Diskussion über den Prozess des Lastausgleichs und der Anwendungsbereitstellung.
Nachdem wir dieses allgemeine Vokabular festgelegt haben, untersuchen wir die einfache Transaktion, mit der die Anwendung an den Kunden übermittelt wird. Wie dargestellt, befindet sich der ADC für den Lastausgleich normalerweise zwischen dem Client und den Hosts, die die Dienste bereitstellen, die der Client nutzen möchte. Wie bei den meisten Dingen bei der Anwendungsbereitstellung ist diese Positionierung keine Regel, sondern eher eine bewährte Vorgehensweise bei jeder Art der Bereitstellung. Nehmen wir außerdem an, dass der ADC bereits mit einem virtuellen Server konfiguriert ist, der auf einen Cluster aus zwei Servicepunkten verweist. In diesem Bereitstellungsszenario ist es üblich, dass die Hosts über eine Rückroute verfügen, die zurück zum Load Balancer zeigt, sodass der Rückverkehr auf dem Weg zurück zum Client über diesen abgewickelt wird.
Die grundlegende Transaktion zur Anwendungsbereitstellung läuft wie folgt ab:
Dieses sehr einfache Beispiel ist relativ unkompliziert, es sind jedoch einige wichtige Elemente zu beachten. Erstens sendet der Client, soweit ihm bekannt ist, Pakete an den virtuellen Server und der virtuelle Server antwortet – ganz einfach. Zweitens findet das NAT statt. Dabei ersetzt der ADC die vom Client (des virtuellen Servers) gesendete Ziel-IP durch die Ziel-IP des Hosts, auf den er den Lastenausgleich der Anforderung ausgesucht hat. Der dritte Teil dieses Prozesses macht das NAT „bidirektional“. Die Quell-IP des vom Host zurückgegebenen Pakets ist die IP des Hosts. Würde diese Adresse nicht geändert und das Paket einfach an den Client weitergeleitet, würde der Client ein Paket von jemandem erhalten, von dem er keines angefordert hat, und würde es einfach verwerfen. Stattdessen merkt sich der Load Balancer die Verbindung und schreibt das Paket so um, dass die Quell-IP die des virtuellen Servers ist. Dadurch wird dieses Problem gelöst.
Normalerweise stellen sich an dieser Stelle zwei Fragen: Wie entscheidet der ADC für den Lastenausgleich, an welchen Host die Verbindung gesendet wird? Und was passiert, wenn der ausgewählte Host nicht funktioniert?
Lassen Sie uns zunächst die zweite Frage besprechen. Was passiert, wenn der ausgewählte Host nicht funktioniert? Die einfache Antwort ist, dass auf die Client-Anforderung nicht reagiert wird und der Verbindungsversuch schließlich abläuft und fehlschlägt. Dies ist offensichtlich kein bevorzugter Umstand, da dadurch keine hohe Verfügbarkeit gewährleistet wird. Aus diesem Grund umfassen die meisten Lastausgleichstechnologien eine gewisse Integritätsüberwachung, um zu ermitteln, ob ein Host tatsächlich verfügbar ist, bevor versucht wird, Verbindungen zu ihm zu senden.
Es gibt mehrere Ebenen der Integritätsüberwachung, jede mit zunehmender Detailliertheit und Fokussierung. Ein einfacher Monitor würde einfach den Host selbst anpingen. Wenn der Host nicht auf den Ping antwortet, kann davon ausgegangen werden, dass alle auf dem Host definierten Dienste wahrscheinlich ausgefallen sind und aus dem Cluster der verfügbaren Dienste entfernt werden sollten. Selbst wenn der Host auf den Ping antwortet, bedeutet dies leider nicht unbedingt, dass der Dienst selbst funktioniert. Daher können die meisten Geräte „Service-Pings“ irgendeiner Art durchführen, von einfachen TCP-Verbindungen bis hin zur Interaktion mit der Anwendung über eine Skript- oder intelligente Interaktion. Diese Integritätsmonitore auf höherer Ebene sorgen nicht nur für mehr Vertrauen in die Verfügbarkeit der tatsächlichen Dienste (im Gegensatz zum Host), sondern ermöglichen dem Load Balancer auch, zwischen mehreren Diensten auf einem einzigen Host zu unterscheiden. Der Lastenausgleich berücksichtigt, dass zwar ein Dienst möglicherweise nicht verfügbar ist, andere Dienste auf demselben Host jedoch möglicherweise einwandfrei funktionieren und dennoch als gültige Ziele für den Benutzerverkehr betrachtet werden sollten.
Dies bringt uns zurück zur ersten Frage: Wie entscheidet der ADC, an welchen Host eine Verbindungsanfrage gesendet werden soll? Jeder virtuelle Server verfügt über einen bestimmten dedizierten Cluster von Diensten (mit einer Liste der Hosts, die diesen Dienst anbieten), der die Liste der Möglichkeiten bildet. Darüber hinaus ändert die Integritätsüberwachung diese Liste, um eine Liste der „derzeit verfügbaren“ Hosts zu erstellen, die den angegebenen Dienst bereitstellen. Aus dieser geänderten Liste wählt der ADC den Host aus, der eine neue Verbindung erhält. Die Entscheidung für den genauen Host hängt vom Lastausgleichsalgorithmus ab, der dem jeweiligen Cluster zugeordnet ist. Zu diesen Algorithmen gehören unter anderem Least Connections, Dynamic Ratio und ein einfaches Round Robin-Verfahren, bei dem der Load Balancer die Liste von oben beginnend durchgeht und jede neue Verbindung dem nächsten Host zuweist; wenn er das Ende der Liste erreicht hat, beginnt er einfach wieder von vorne. Dies ist zwar einfach und sehr vorhersehbar, setzt aber voraus, dass alle Verbindungen auf dem Back-End-Host eine ähnliche Belastung und Dauer aufweisen, was nicht immer der Fall ist. Fortgeschrittenere Algorithmen nutzen Faktoren wie die Anzahl der aktuellen Verbindungen, die Host-Auslastung und sogar reale Antwortzeiten für den vorhandenen Datenverkehr zum Host, um den am besten geeigneten Host aus den verfügbaren Cluster-Diensten auszuwählen.
Ausreichend fortgeschrittene Anwendungsbereitstellungssysteme werden außerdem in der Lage sein, Informationen zur Integritätsüberwachung mit Lastausgleichsalgorithmen zu synthetisieren, um ein Verständnis der Dienstabhängigkeit zu ermöglichen. Dies ist vor allem dann nützlich, wenn ein einzelner Host über mehrere Dienste verfügt, die alle zur Erfüllung der Benutzeranforderung erforderlich sind. In einem solchen Fall möchten Sie nicht, dass ein Benutzer zu einem Host wechselt, auf dem ein Dienst betriebsbereit ist, der andere jedoch nicht. Mit anderen Worten: Wenn ein Dienst auf dem Host ausfällt, möchten Sie, dass auch der andere Dienst des Hosts aus der Clusterliste der verfügbaren Dienste entfernt wird. Diese Funktionalität wird zunehmend wichtiger, da die Dienste durch HTML und Skripting immer differenzierter werden.
Der Teil des Lastenausgleichs, bei dem ein verfügbarer Dienst ausgewählt wird, wenn ein Client eine Transaktionsanforderung initiiert, ist nur die Hälfte der Lösung. Sobald die Verbindung hergestellt ist, muss der ADC verfolgen, ob für den folgenden Datenverkehr dieses Benutzers ein Lastenausgleich erfolgen soll. Bei der Handhabung von Folgeverkehr nach erfolgtem Lastenausgleich gibt es im Allgemeinen zwei spezielle Probleme: Verbindungswartung und Persistenz.
Wenn der Benutzer versucht, eine langlebige TCP-Verbindung zu nutzen (Port 21: FTP, Port 23: Wenn die Verbindung beispielsweise über eine Verbindung mit Telnet oder einer anderen Verbindung hergestellt wird, die nicht sofort geschlossen wird, muss der Lastenausgleich sicherstellen, dass mehrere über diese Verbindung übertragene Datenpakete nicht per Lastenausgleich auf andere verfügbare Service-Hosts verteilt werden. Dies dient der Verbindungswartung und erfordert zwei wichtige Funktionen. Die erste ist die Möglichkeit, den Überblick über offene Verbindungen und den Host-Dienst, zu dem sie gehören, zu behalten. Zweitens muss der Load Balancer in der Lage sein, diese Verbindung weiterhin zu überwachen, damit die Verbindungstabelle aktualisiert werden kann, wenn die Verbindung geschlossen wird. Dies ist für die meisten ADCs eher Standard.
Immer häufiger kommt es jedoch vor, dass der Client mehrere kurzlebige TCP-Verbindungen verwendet (z. B. Port 80: HTTP), um eine einzelne Aufgabe auszuführen. In manchen Fällen, etwa beim normalen Surfen im Internet, spielt dies keine Rolle und jede neue Anforderung kann an jeden beliebigen Back-End-Diensthost gesendet werden. Es gibt jedoch viele Fälle (XML, E-Commerce usw.), in denen es äußerst wichtig ist, dass mehrere Verbindungen desselben Benutzers an denselben Back-End-Diensthost gesendet werden und kein Lastenausgleich erfolgt. Dieses Konzept wird Persistenz oder Serveraffinität genannt.
Hierfür gibt es je nach Protokoll und gewünschten Ergebnissen mehrere Möglichkeiten. Beispielsweise kann der Server bei modernen HTTP-Transaktionen eine „Keep-Alive“-Verbindung angeben, die diese mehreren kurzlebigen Verbindungen in eine einzige langlebige Verbindung umwandelt, die genauso gehandhabt werden kann wie die anderen langlebigen Verbindungen. Dies schafft allerdings nur wenig Abhilfe, vor allem weil bei zunehmender Nutzung von Web- und Mobildiensten das Aufrechterhalten aller Verbindungen länger als nötig die Ressourcen des gesamten Systems belastet. Aus diesem Grund gehen heute viele Unternehmen – im Interesse der Skalierbarkeit und Portabilität – dazu über, zustandslose Anwendungen zu erstellen, die auf APIs basieren. Dies bedeutet im Wesentlichen, dass der Server alle Sitzungsinformationen vergisst, um die Belastung der Ressourcen zu verringern. In diesen Fällen wird der Status durch die Weitergabe von Sitzungs-IDs sowie durch das Konzept der Persistenz aufrechterhalten.
Eine der grundlegendsten Formen der Persistenz ist die Quelladressaffinität. Dabei werden lediglich die Quell-IP-Adresse eingehender Anforderungen und der Service-Host, auf den die Last verteilt wurde, aufgezeichnet und alle zukünftigen Transaktionen werden an denselben Host gesendet. Dies lässt sich auf zwei Arten erreichen: durch die Verwendung von SSL-Sitzungs-IDs und Cookies. SSL-Persistenz verfolgt SSL-Sitzungen anhand von SSL-Sitzungs-IDs. Das bedeutet, dass der Load Balancer selbst dann, wenn sich die IP-Adresse des Clients ändert, anhand der Sitzungs-ID erkennt, dass die Sitzung persistent ist. Cookie-basierte Persistenz bietet die Möglichkeit, ein Cookie auf dem Computer eines Clients einzufügen, um eine Sitzung eindeutig zu identifizieren und dann in Anfragen auf dieses Cookie zu verweisen, sodass die Verbindung zum richtigen Server geht.
Heutzutage ermöglicht die Intelligenz von ADCs Organisationen, die Datenpakete zu öffnen und Persistenztabellen für praktisch alles darin enthaltene Material zu erstellen. Dadurch können sie zur Wahrung der Persistenz eindeutige Informationen, beispielsweise den Benutzernamen, verwenden. Unternehmen müssen jedoch sicherstellen, dass diese identifizierbaren Clientinformationen in jeder Anfrage vorhanden sind, da Pakete ohne diese Informationen nicht gespeichert werden und erneut einem Lastenausgleich unterzogen werden, was höchstwahrscheinlich zu einem Abbruch der Anwendung führt.
Zu Beginn konzentrierte sich der Lastenausgleich auf die Verteilung der Arbeitslast im gesamten Netzwerk und die Sicherstellung der Verfügbarkeit von Anwendungen und Diensten. Im Zuge der technologischen Weiterentwicklung wurden Load Balancer jedoch zu Plattformen für die Anwendungsbereitstellung und gewährleisteten so die hohe Verfügbarkeit und Sicherheit der unternehmenskritischen Anwendungen. Während der grundlegende Lastausgleich weiterhin die Grundlage der Anwendungsbereitstellung bildet, bieten moderne ADCs weitaus erweiterte Funktionen.
Unternehmen sind sich bewusst, dass die bloße Erreichbarkeit einer Anwendung diese nicht automatisch nutzbar macht. Und unbrauchbare Anwendungen bedeuten für das Unternehmen, das sie einsetzt, Zeit- und Geldverschwendung. Hier kommt der moderne ADC ins Spiel: Er ermöglicht es Unternehmen, netzwerkbasierte Dienste wie SSL/TLS-Offload, Caching, Komprimierung, Rate-Shaping, Intrusion Detection, Anwendungs-Firewalls und sogar Remote-Zugriff an einem einzigen strategischen Punkt zu konsolidieren, der von allen Anwendungsdiensten und allen Hosts gemeinsam genutzt und wiederverwendet werden kann, um ein virtualisiertes Application Delivery Network zu erstellen. Dadurch können Netzwerk-, Anwendungs- und Betriebsteams besser auf Geschäftsanforderungen nach kürzeren Lieferzeiten und größerer Skalierbarkeit reagieren – ohne dabei die Sicherheit zu vernachlässigen.
Wenn Sie mehr über die Funktionsweise der erweiterten Anwendungsbereitstellung und die Zukunft von ADCs erfahren möchten, lesen Sie Die Entwicklung von Application Delivery Controllern und Gehen Sie über das gute alte Load Balancing hinaus .