Die Entwicklung von Application Delivery Controllern

In der dynamischen Welt von heute stehen Unternehmen ständig vor der Herausforderung, Millionen von Benutzern rund um den Globus geschäftskritische Applications bereitzustellen. Es ist äußerst wichtig, dass sie Netzwerk- und Application bereitstellen, um Apps skalierbar, sicher und verfügbar zu machen. Dies ist einer der Hauptgründe für die Entwicklung von Application Delivery Controllern (ADCs). Keine dieser Funktionen kann jedoch ohne eine solide Grundlage in der grundlegenden Lastausgleichstechnologie implementiert werden. Beginnen wir also damit, die Bedeutung des Lastenausgleichs zu verstehen, wie er zu einer effizienten Application führt und wie sich ADCs weiterentwickeln und die Cloud-First-Welt annehmen.

Der Sinn des Lastenausgleichs besteht darin, den eingehenden Netzwerk- oder Application auf viele physische Server zu verteilen und diese Server für die Außenwelt wie einen einzigen Server aussehen zu lassen. Die Gründe hierfür sind vielfältig, die wichtigsten sind jedoch die Notwendigkeit von „Skalierbarkeit“, „hoher Verfügbarkeit“ und „Vorhersehbarkeit“.

Skalierbarkeit ist die Fähigkeit, sich dynamisch bzw. einfach an eine erhöhte Last anzupassen, ohne die vorhandene Leistung zu beeinträchtigen. Hohe Verfügbarkeit (HA) hingegen ist die Fähigkeit einer Site, auch bei einem Ausfall eines oder mehrerer Systeme verfügbar und zugänglich zu bleiben. Die Service-Virtualisierung (Nachahmung des Verhaltens von Softwarekomponenten zum Beschleunigen und Testen der Application ) bietet eine interessante Möglichkeit sowohl hinsichtlich Skalierbarkeit als auch Verfügbarkeit. Wenn der Dienst bzw. Benutzerkontaktpunkt von den eigentlichen Servern getrennt ist, kann die Application durch Hinzufügen weiterer Server skaliert werden. Darüber hinaus führt der Ausfall eines einzelnen Servers nicht dazu, dass die gesamte Application nicht verfügbar ist. Die Vorhersagbarkeit ist etwas weniger klar, da sie sowohl Teile von HA als auch einige im Laufe der Zeit gewonnene Erkenntnisse darstellt. Am besten lässt es sich so beschreiben, dass man Kontrolle darüber hat, wie und wann die Dienste im Hinblick auf Verfügbarkeit und Leistung bereitgestellt werden.

In den Anfangstagen des kommerziellen Internets entdeckten viele angehende Dotcom-Millionäre ein ernstes Problem in ihren Plänen. Mainframes verfügten nicht über Webserver-Software (jedenfalls nicht bis zum AS/400e), und selbst wenn sie eine gehabt hätten, konnten sie sich diese aufgrund ihrer Gründungsbudgets nicht leisten. Was sie sich leisten konnten, war standardmäßige, handelsübliche Serverhardware von einem der allgegenwärtigen PC-Hersteller. Das Hauptproblem bei den meisten von ihnen bestand darin, dass ein einzelner PC-basierter Server niemals in der Lage wäre, den Datenverkehr zu bewältigen, den ihr Unternehmen generierte. Und wenn es ausfiel, waren sie offline und konnten ihr Geschäft nicht mehr führen. Glücklicherweise hatten einige dieser Leute Pläne, mit der Lösung dieses speziellen Problems Millionen zu machen. Dies führte zur Geburt des Lastausgleichs.

Bevor es kommerziell erhältliche, speziell entwickelte Lastausgleichsgeräte gab, gab es viele Versuche, die vorhandene Technologie zu nutzen, um die Ziele Skalierbarkeit und Verfügbarkeit zu erreichen. Die am weitesten verbreitete (und immer noch verwendete) Technologie war DNS-Round-Robin.

Bei dieser Methode würde das DNS verschiedenen Servern unter demselben DNS-Namen eine Reihe eindeutiger IP-Adressen zuweisen. Dies bedeutete, dass der DNS-Server bei der ersten Anforderung einer Auflösung für „ www.example.com “ durch einen Benutzer jede neue Verbindung an den ersten Server in der Reihe weiterleitete, bis er das Ende der Reihe erreichte – und dann wieder zum ersten Server zurückkehrte. Diese Lösung war einfach und führte zu einer gleichmäßigen Verteilung der Verbindungen auf eine Reihe von Maschinen.

Aus Skalierbarkeitssicht funktionierte diese Lösung bemerkenswert gut, da sie die Möglichkeit bot, einem DNS-Namen eine nahezu unbegrenzte Anzahl von Servern hinzuzufügen. In Bezug auf die Verfügbarkeit stellte die Lösung jedoch ein Hindernis dar, da das DNS nicht erkennen konnte, ob die aufgelisteten Server funktionierten oder nicht. Wenn ein Server nicht verfügbar ist und ein Benutzer versucht, darauf zuzugreifen, wird die Anforderung möglicherweise an einen ausgefallenen Server gesendet.

Ein weiterer Treiber des DNS-Round-Robin war die Vorhersagbarkeit, also ein hohes Maß an Sicherheit, dass ein Benutzer an einen bestimmten Server gesendet wird. Im Mittelpunkt steht dabei die Idee der Persistenz – das Konzept, sicherzustellen, dass die Last eines Benutzers nicht auf einen neuen Server verlagert wird, nachdem eine Sitzung begonnen hat oder wenn der Benutzer eine zuvor unterbrochene Sitzung fortsetzt. Dies ist ein sehr wichtiges Problem, das durch DNS-Round-Robin nicht gelöst werden konnte.

Eine der ersten speziellen Lösungen zur Lösung dieses Problems bestand in der Lastverteilung, die direkt in die Application oder das Betriebssystem (OS) des Application integriert wurde. Zwar gab es so viele unterschiedliche Implementierungen wie Unternehmen, die sie entwickelten, doch die meisten Lösungen drehten sich um grundlegende Netzwerktricks. Bei einer solchen Lösung waren beispielsweise alle Server in einem Pool (auch Cluster genannt) zusammengefasst und verfügten zusätzlich über eine eigene physische IP-Adresse.

Als Benutzer versuchten, eine Verbindung zum Dienst herzustellen, stellten sie eine Verbindung zur Pool-IP statt zur physischen IP des Servers her. Der Server im Pool, der zuerst auf die Verbindungsanforderung antwortete, leitete den Benutzer zu einer physischen IP-Adresse um (entweder seiner eigenen oder einem anderen System im Pool), und die Service-Sitzung wurde gestartet. Einer der Hauptvorteile dieser Lösung bestand darin, dass die Application anhand einer Vielzahl von Informationen bestimmen konnten, mit welcher physischen IP-Adresse sich der Client verbinden sollte. Sie könnten beispielsweise jeden Server im Pool so konfigurieren, dass er zählt, wie viele Sitzungen jedes Poolmitglied bereits bedient, und dann alle neuen Anforderungen an den am wenigsten ausgelasteten Server umleitet.

Die Skalierbarkeit dieser Lösung war zunächst klar. Sie mussten lediglich einen neuen Server erstellen und ihn dem Pool hinzufügen, und schon konnten Sie die Kapazität Ihrer Application erweitern. Mit der Zeit wurde jedoch die Skalierbarkeit des anwendungsbasierten Lastausgleichs in Frage gestellt. Da die Poolmitglieder ständig miteinander in Kontakt bleiben mussten, um zu klären, an wen die nächste Verbindung gehen sollte, stieg der Netzwerkverkehr zwischen den Poolmitgliedern mit jedem neuen Server, der zum Pool hinzugefügt wurde, exponentiell an. Nachdem der Pool eine bestimmte Größe erreicht hatte (normalerweise 5–10 Hosts), begann dieser Datenverkehr den Endbenutzerdatenverkehr sowie die Prozessorauslastung der Server selbst zu beeinträchtigen. Die Skalierbarkeit war also großartig, solange Sie eine geringe Anzahl an Servern nicht überschreiten mussten (übrigens weniger als beim DNS-Round-Robin).

Die HA wurde durch DNS-Round-Robin und Software-Lastausgleich erheblich erhöht. Da die Poolmitglieder in ständiger Kommunikation miteinander standen und die Application dank ihrer umfassenden Application feststellen konnten, wann ein Server ordnungsgemäß lief, war es mit diesen Lösungen praktisch ausgeschlossen, dass Benutzer jemals auf einen Server gelangten, der ihre Anfragen nicht bearbeiten konnte. Es muss jedoch darauf hingewiesen werden, dass jede Iteration der Intelligenz ermöglichenden HA-Eigenschaften entsprechende Auswirkungen auf die Server- und Netzwerkauslastung hatte, was die Skalierbarkeit weiter einschränkte. Die anderen negativen HA-Auswirkungen betrafen den Bereich der Zuverlässigkeit. Viele der Netzwerktricks, die zur Verteilung des Datenverkehrs in diesen Systemen verwendet wurden, waren komplex und erforderten eine umfassende Überwachung auf Netzwerkebene. Dementsprechend traten bei diesen Verteilungsmethoden häufig Probleme auf, die die gesamte Application und den gesamten Datenverkehr im Application betrafen.

Diese Lösungen verbesserten auch die Vorhersagbarkeit. Da die Application wussten, wann und warum Benutzer an denselben Server zurückgeleitet werden mussten, anstatt eine Lastverteilung vorzunehmen, konnten sie eine Logik einbetten, die dazu beitrug, sicherzustellen, dass die Benutzer bei Bedarf persistent bleiben. Sie verwendeten außerdem dieselbe „Pooling“-Technologie, um Benutzerstatusinformationen zwischen Servern zu replizieren, wodurch viele der Instanzen eliminiert wurden, die von vornherein Persistenz erforderten. Und schließlich waren sie aufgrund ihrer umfassenden Application besser in der Lage, Lastausgleichsalgorithmen zu entwickeln, die auf dem tatsächlichen Zustand der Application basierten, statt auf Faktoren wie Verbindungen, die nicht immer ein guter Indikator für die Serverauslastung waren.

Neben den potenziellen Einschränkungen der tatsächlichen Skalierbarkeit und Zuverlässigkeitsproblemen hatte der proprietäre, anwendungsbasierte Lastausgleich noch einen weiteren Nachteil: Die Entwicklung und Wartung war vom Application abhängig. Das Hauptproblem bestand darin, dass nicht alle Applications über eine Technologie zum Lastenausgleich (bzw. Pooling) verfügten und die Anwendungen, die über eine solche Technologie verfügten, häufig nicht mit den Technologien anderer Application funktionierten. Zwar gab es mehrere Organisationen, die herstellerneutrale Lastausgleichssoftware auf Betriebssystemebene herstellten, doch leider litten sie unter denselben Skalierbarkeitsproblemen. Und ohne enge Integration mit den Applications waren diese Softwarelösungen auch mit zusätzlichen HA-Herausforderungen konfrontiert.

Die zweite Iteration des speziell entwickelten Lastausgleichs erfolgte in Form netzwerkbasierter Geräte. Dies sind die wahren Gründerväter der heutigen Application Delivery Controller. Diese Geräte befanden sich physisch außerhalb der eigentlichen Applications und obwohl sie ursprünglich als Lastverteiler dienten, wurde ihr Lastausgleich mithilfe viel einfacherer Netzwerktechniken wie NAT erreicht. Diese Geräte präsentieren der Außenwelt eine virtueller Server und leiten beim Verbindungsversuch der Benutzer die Verbindung an den am besten geeigneten realen Server weiter.

Der Load Balancer konnte genau steuern, welcher Server welche Verbindung erhielt und setzte „Health Monitore“ von zunehmender Komplexität ein, um sicherzustellen, dass der Application (ein echter, physischer Server) wie erforderlich reagierte. Wenn der Server nicht richtig reagierte, stoppte der Load Balancer automatisch die Übermittlung von Datenverkehr an diesen Server, bis die gewünschte Antwort erfolgte. Auch wenn die Integritätsmonitore selten so umfassend waren wie die von den Application selbst erstellten, konnte der netzwerkbasierte Hardwareansatz grundlegende Lastausgleichsdienste für nahezu jede Application auf einheitliche und konsistente Weise bereitstellen – und so schließlich einen wirklich virtualisierten Diensteinstiegspunkt schaffen, der für die Application eindeutig war.

Aus Skalierbarkeitssicht verzeichneten Unternehmen, die begannen, den softwarebasierten Lastenausgleich durch eine hardwarebasierte Lösung zu ersetzen, einen dramatischen Rückgang der Serverauslastung. Dadurch mussten sie kurzfristig keine zusätzlichen Server anschaffen und konnten langfristig ihren ROI steigern.

Ebenso trug HA dazu bei, die Komplexität der Lösung zu reduzieren und einen anwendungsunabhängigen Lastausgleich bereitzustellen, was zu einer höheren Zuverlässigkeit und größeren Tiefe der Lösung führte. Netzwerkbasierte Lastausgleichshardware ermöglichte es dem Geschäftsinhaber, für alle seine Applications ein hohes Maß an Verfügbarkeit bereitzustellen, anstatt nur für einige wenige mit integriertem Lastausgleich.

Vorhersagbarkeit war eine Kernkomponente, die durch die netzwerkbasierte Lastausgleichshardware hinzugefügt wurde. Es war nun viel einfacher vorherzusagen, wohin eine neue Verbindung geleitet würde, und sie zu manipulieren. Diese Geräte fügten dem Prozess Intelligenz hinzu, was wiederum zu einer kontrollierten Lastverteilung beitrug (im Gegensatz zur unkontrollierten Verteilung von dynamischem DNS). Dadurch konnten Unternehmensinhaber die Last auf die Server entsprechend ihrer Fähigkeit, die Last zu bewältigen, verteilen.

Die Einführung netzwerkbasierter Lastenausgleichsfunktionen und Virtualisierung brachte neue Vorteile für die Sicherheit und Verwaltung mit sich, beispielsweise die Maskierung der Identität von Application vor der Internet-Community und die Möglichkeit, Verbindungen von einem Server zu trennen, sodass dieser ohne Auswirkungen auf die Benutzer zu Wartungsarbeiten offline genommen werden kann. Dies ist die Grundlage, auf der ADCs entstanden sind.

Mit einer zentralen Lastausgleichsfunktion, die zugleich ein Vollproxy ist, sah die IT eine hervorragende Möglichkeit, neue und aufkommende Dienste hinzuzufügen und zu konsolidieren. Dies führte dazu, dass sich ein Lastausgleichsgerät zu einer erweiterbaren ADC-Plattform entwickelte. Einfach ausgedrückt ist ein Proxy die Grundlage für die Lastverteilung und die zugrunde liegende Technologie, die ADCs ermöglicht.  

Bei der Diskussion über ADC-Sicherheit ist die durch Proxy (die Basistechnologie) erstellte Virtualisierung von entscheidender Bedeutung. Unabhängig davon, ob es um die Auslagerung der SSL/TLS-Verschlüsselung, eine zentralisierte Authentifizierung oder sogar anwendungsorientierte Firewalls geht, liegt die Stärke dieser Lösungen darin, dass ein Load Balancer (Hardware- oder virtuelle Edition) den aggregierten Punkt der Virtualisierung für alle Applications darstellt. Ein klassisches Beispiel ist die zentralisierte Authentifizierung. Herkömmliche Authentifizierungs- und Autorisierungsmechanismen waren schon immer direkt in die Application selbst integriert. Wie beim anwendungsbasierten Lastenausgleich war jede Implementierung von der Implementierung der einzelnen Anwendungen abhängig und für diese einzigartig, was zu zahlreichen und unterschiedlichen Methoden führte. Stattdessen kann durch die Anwendung der Authentifizierung am virtualisierten Einstiegspunkt auf alle Applications eine einzige, einheitliche Authentifizierungsmethode angewendet werden. Dadurch werden nicht nur die Gestaltung und Verwaltung des Authentifizierungssystems erheblich vereinfacht, sondern auch die Leistung der Application selbst verbessert, da diese Funktion nicht mehr ausgeführt werden muss. Darüber hinaus entfällt – insbesondere bei selbst entwickelten Applications– die Notwendigkeit, Zeit und Geld in die Entwicklung von Authentifizierungsprozessen in jeder einzelnen Application zu investieren.

Die Verfügbarkeit ist das ADC-Attribut, das sich am einfachsten mit dem ursprünglichen Load Balancer verknüpfen lässt, da es sich auf alle grundlegenden Load Balancer-Attribute bezieht: Skalierbarkeit, hohe Verfügbarkeit und Vorhersagbarkeit. ADCs gehen jedoch noch weiter als der Load Balancer. Die Verfügbarkeit für ADCs stellt auch erweiterte Konzepte wie Application und dynamische Bereitstellung dar. ADCs sind in der Lage zu verstehen, dass Applications heutzutage nur noch selten in sich geschlossen arbeiten: Sie sind zur Erfüllung ihres Entwurfs häufig auf andere Applications angewiesen. Dieses Wissen erhöht die Fähigkeit des ADC, die Application sicherzustellen, indem auch diese anderen Prozesse berücksichtigt werden. Die intelligentesten ADCs auf dem Markt verfügen außerdem über Programmierschnittstellen, die es ihnen ermöglichen, die Art und Weise, wie sie Dienste bereitstellen, dynamisch auf der Grundlage externer Eingaben zu ändern. Diese Schnittstellen ermöglichen die dynamische Bereitstellung und das automatische Hoch-/Herunterskalieren, das für moderne Umgebungen wie Cloud- und Containerbereitstellungen erforderlich ist.

Eine weitere offensichtliche Erweiterung des Lastausgleichskonzepts war die Leistungssteigerung. Lastenausgleichsmodule verbesserten grundsätzlich die Leistung von Applications , indem sie sicherstellten, dass Verbindungen nicht nur an Dienste weitergeleitet wurden, die verfügbar waren (und in einem akzeptablen Zeitrahmen reagierten), sondern auch an die Dienste mit der geringsten Anzahl an Verbindungen und/oder Prozessorauslastung. Dadurch wurde sichergestellt, dass jede neue Verbindung von dem System bedient wurde, das am besten dazu in der Lage war. Später, als sich SSL/TLS-Offload (mithilfe dedizierter Hardware) zu einem gängigen Bestandteil von Lastenausgleichsangeboten entwickelte, verringerte sich dadurch der Rechenaufwand des verschlüsselten Datenverkehrs sowie die Belastung der Back-End-Server – und damit auch deren Leistung.

Die heutigen ADCs gehen noch weiter. Diese Geräte verfügen häufig über Caching-, Komprimierungs- und sogar Rate-Shaping-Technologien, um die Gesamtleistung und Bereitstellung von Applications weiter zu verbessern. Darüber hinaus handelt es sich bei einem ADC nicht um statische Implementierungen herkömmlicher eigenständiger Geräte, die diese Dienste bereitstellen, sondern er kann seine inhärente Anwendungsintelligenz nutzen, um diese Dienste nur dann anzuwenden, wenn sie einen Leistungsvorteil bringen – und so ihre Nutzung zu optimieren.

Zum Beispiel Kompressionstechnologie – entgegen der landläufigen Meinung – nicht unbedingt für alle Benutzer der Application von Vorteil ist. Benutzer mit geringer Bandbreite können sicherlich enorm von kleineren Paketen profitieren, da der Engpass beim tatsächlichen Durchsatz liegt. Sogar Verbindungen, die lange Distanzen überwinden müssen, können davon profitieren, da kleinere Pakete weniger Hin- und Rückwege zum Transport von Daten bedeuten und sich die Auswirkungen der Netzwerklatenz verringern. Bei Kurzstreckenverbindungen (zum Beispiel innerhalb desselben Kontinents) mit großer Bandbreite kann es jedoch bei der Anwendung einer Komprimierung zu einer schlechteren Leistung kommen. Da der Durchsatz nicht unbedingt den Engpass darstellt, führt der zusätzliche Aufwand für Komprimierung und Dekomprimierung zu einer Latenz, die der erhöhte Durchsatz aus Leistungssicht nicht ausgleicht. Mit anderen Worten: Bei unsachgemäßer Handhabung kann die Komprimierungstechnologie als Lösung schlimmer sein als das ursprüngliche Problem. Indem die Komprimierung jedoch nur dann intelligent angewendet wird, wenn sie sich positiv auf die Gesamtleistung auswirkt, optimiert ein ADC den Einsatz und die Kosten der Komprimierungstechnologie, sodass mehr Prozessorzyklen für Funktionen übrig bleiben, die diese am meisten nutzen.

Da die digitale Transformation ein so wichtiges strategisches Gebot ist, haben viele Unternehmen bereits begonnen, ihre Reise in die Cloud anzutreten. Angesichts der steigenden Anzahl von Applications , die die Welt um uns herum verändern, ist man davon überzeugt, dass Unternehmen, die in die Cloud migrieren, viele Vorteile genießen werden, wie etwa eine höhere Flexibilität, besser abgestimmte Betriebskosten, Skalierbarkeit nach Bedarf und eine stärkere Konzentration auf ihr Kerngeschäft.  

Die „Cloud“ ist keine amorphe Einzeleinheit mit gemeinsam genutzten Rechen-, Speicher- und Netzwerkressourcen; sie besteht vielmehr aus einem komplexen Mix aus Anbietern, Infrastrukturen, Technologien und Umgebungen, die oft in mehreren globalen Knotenpunkten bereitgestellt werden. Aus diesem Grund haben viele Unternehmen applications in mehreren unterschiedlichen Clouds bereitgestellt – öffentlichen, privaten und sogar einer Kombination aus allen. Das ist Multi-Cloud: die neue Realität.

Trotz dieser sich rasch entwickelnden Landschaft gibt es mehrere Faktoren, die die Einführung der Cloud verlangsamen. Die erste Herausforderung besteht in der Ausbreitung von Multi-Cloud-Anwendungen, bei der vorhandene Applications „gehoben und verschoben“ und „in der Cloud geborene“ Applications ungeplant und ohne Verwaltung bereitgestellt werden. Darüber hinaus neigen Unternehmen dazu, zur Deckung ihres kurzfristigen Bedarfs unterschiedliche Cloud-Plattformen, verschiedene Architekturen, verschiedene Application und mehrere Tool-Sets zu verwenden. Dies führt zu einer komplexen Architektur im gesamten Unternehmen und erschwert und kostspielig die Verlagerung von Applications von einer Umgebung in eine andere.

ADCs sind die natürliche Weiterentwicklung des kritischen Netzwerkplatzes, der in der Vergangenheit von Load Balancern belegt wurde. Obwohl ADCs diesen Geräten von gestern viel zu verdanken haben, handelt es sich bei ihnen um eine deutlich neue Generation, die nicht nur Verfügbarkeit, sondern auch Leistung und Sicherheit bietet. Wie der Name schon sagt, kümmern sie sich um alle Aspekte der bestmöglichen Bereitstellung einer Application .

Mit erweiterten Funktionen wie Anwendungsintelligenz, SSL-Offload und programmierbaren Schnittstellen können moderne ADCs Unternehmen dabei helfen, ihr Geschäft zu skalieren und Benutzer jederzeit und überall zu erreichen. Angesichts der sich ständig ändernden Anforderungen der technischen Welt sind die ADCs auch besser in der Lage, sich an die neuesten Technologien in Multi-Cloud- und Containerumgebungen anzupassen.

Letztendlich können wir mit Sicherheit sagen, dass ADCs nicht nur der primäre Kanal und Integrationspunkt sein werden, über den die Applications schneller, intelligenter und sicherer bereitgestellt werden, sondern dass sie sich auch weiterhin weiterentwickeln und die Cloud-First-Welt annehmen werden.