Azure stellt für mehr Performanz und Ausfallsicherheit verwaltete Dienste bereit, die sich funktional teils überschneiden. Je nach Einsatzzweck lassen sie sich aber sinnvoll kombinieren. Dieser Artikel soll für mehr Durchblick sorgen und stellt die wichtigsten Services dieser Kategorie einander gegenüber.
Azure Front Door
Azure Front Door (AFD) ist ein Dienst, mit dem sich Webservices global ausfallsicher und mit optimierter Performance ausliefern lassen. Insofern kombiniert der Dienst Aspekte von Lastausgleich, hoher Verfügbarkeit und Beschleunigung im Sinne von Content Delivery in einem einzigen verwalteten Service. Front Door überschneidet sich dabei funktional mit den Azure-Diensten „Traffic Manager“ (globaler Lastausgleich), „Application Gateway“ (Lastausgleich auf HTTP/S-Ebene) und „Azure Content Delivery Network“ (Beschleunigung). Genau genommen ist Front Door eine von vier Auslieferungsformen von Azure Content Delivery.
Formal ist Front Door als globaler, (in sich) skalierbarer Einstiegspunkt definiert, der das globale Microsoft-Edge-Netzwerk nutzt, um schnelle, sichere und global skalierbare Webanwendungen zu erstellen. Kunden können also ihre globalen Consumer- oder Unternehmensanwendungen mittels Front Door in robuste, leistungsfähige moderne Anwendungen transformieren.
Technisch betrachtet ist Azure Front Door ein Application Delivery Network (ADN). Ein solcher Dienst bietet verschiedene Lastenausgleichsfunktionen auf Schicht 7 für moderne Web-Anwendungen. Der Service kombiniert die Beschleunigung dynamischer Websites (Dynamic Site Acceleration, DSA) mit globalem Lastenausgleich und Failover in Echtzeit.
Da der Service vollständig von Azure verwaltet wird, ist er hoch verfügbar und skalierbar. Zudem unterstützt Front Door TLS/SSL-Offloading, Ende-zu-Ende-TLS, die Azure Web Application Firewall, Cookie-basierte Sitzungsaffinität, Routing auf URL-Pfadbasis, kostenlose Zertifikate, die Verwaltung mehrerer Domänen und viele weitere Features.
Während die Gemeinsamkeit zwischen Front Door und Application Gateway den Lastenausgleich auf Schicht 7 (HTTP/HTTPS) betrifft, ist der wesentliche Unterschied, dass Front Door einen globalen und Application Gateway einen regionalen Dienst darstellt. Mit dem Application Gateway lassen sich also nur Anwendungen innerhalb einer Azure-Region lastausgeglichen betreiben; neben Azure Web Apps auch selbstgebaute, auf IaaS basierende Anwendungen mit VMs, Scale Sets oder externe öffentliche Endpunkte.
Mit Front Door dagegen können Admins nahezu beliebige Web Anwendungen betreiben. Konkret nutzt Front Door dazu das Konzept des Anwendungs-Backend. Darunter versteht Front Door wiederum einen unterstützten Dienst mit Internetzugriff. Der kann allerdings immer innerhalb oder außerhalb von Azure gehostet sein. Die weitere Besonderheit bei Front Door gegenüber Application Gateway ist, dass Front Door in Schicht 7 (HTTP/HTTPS-Schicht) das Anycast-Protokoll Split TCP nutzt.
Der Beschleunigungseffekt kommt nicht nur dadurch zustande, sondern auch durch Nutzung des globalen Backbone-Netzwerks von Microsoft und durch das Caching-Konzept. Hierbei werden über das Microsoft-Backbone-Netzwerk ausgelieferte Objekte an einer der Front Door Edge-Locations zwischengespeichert. So können System-Architekten auf Basis der gewählten Routing-Methode sicherstellen, dass Front Door Client-Anforderungen immer an das schnellste und am höchsten verfügbarste Anwendungs-Back-End weiterleitet.
Front Door unterstützt eine ganze Reihe von Routing-Methoden, darunter Latenz- und Prioritäts-basiertes Routing, gewichtetes Routing oder URL Rewrite/Redirect. In Bezug auf seine komplexen Routing-Methoden gleicht es eher dem DNS-basierenden Traffic Manager als dem Application Gateway. Mit letzterem hat Front Door gemein, dass eine Integration mit Azure WAF möglich ist. Ähnlichkeiten mit Azure Traffic Manager weist Azure Front Door auch in Bezug auf seine geringe Fehleranfälligkeit aus, selbst wenn es zum Ausfall einer ganzen Azure-Region kommt.
Azure Application Gateway
Das Azure Application Gateway ist ein intelligenter Azure Load Balancer, der im Gegensatz zu diesem (Azure Load Balancer bietet nur Lastausgleich auf Layer 4) auf Request-Ebene des OSI-Modells arbeiten, d. h. er wendet Routing-Regeln an, um den HTTP/S-Lastausgleich (Layer-7) zu unterstützen. Auch Application Gateway bietet eine Integration mit Azure Web Application Firewall, SSL-Terminierung und unterstützt das Routing auf URL-Pfadbasis sowie das Hosten mehrerer Websites. Allerdings ist Application Gateway wie schon erwähnt nur ein regionaler Dienst und kann Anwendungen nicht vor dem Ausfall einer ganzen Region schützen.
Azure Application Gateway unterstützt im Backend neben Azure Web Apps nahezu beliebige Infrastruktur auf Einzel-VMs oder Scale Sets. Außerdem unterstützt das Routing neben URL-Routing auch Umleitungen, d. h. das Application Gateway kann den Datenverkehr, der an einem Listener empfangen wird, an einen anderen Listener oder sogar eine externe Website umleiten. Das gilt aber wie oben gesehen auch bei Front Door.
Azure Traffic Manager
Azure Traffic Manager ist im Prinzip ein DNS Load Balancer für geografisch verteilte Rechenzentren. Azure Traffic Manager nutzt DNS, um Client-Anforderungen auf Basis einer Routing-Methode an den passenden Dienst-Endpunkt weiterzuleiten. Allerdings „sieht“ Traffic Manager den zwischen dem Client und dem Dienst übertragenen Datenverkehr nicht. Die Anforderung wird einfach nur stets zum geeignetsten Endpunkt umgeleitet. Auch hier kann der Endpunkt ein beliebiger Dienst mit Internetzugriff sein, der innerhalb oder außerhalb von Azure gehostet wird.
Ein Beispiel wären zwei Endpunkte, von denen sich der erste in Azure befindet und der zweite im lokalen Datencenter. Auch Traffic Manager unterstützt zahlreiche Routing Methoden darunter Priorität (wird u. a. für Failover-Szenarien genutzt), gewichtet, Latenz-basiert, Geolocation oder Subnetz. Mit der Letztgenannten lassen sich Gruppen von Endbenutzer-IP-Adressbereichen einem bestimmten Endpunkt zuzuordnen. Sämtliche Traffic Manager-Profile unterstützten Integritätsüberwachung und automatisches Failover für Endpunkte
Damit bietet Traffic Manager beim globalen Load Balancing (hier konkurriert er mit Azure Front Door) zum einen die Verteilung von Datenverkehr gemäß einer von mehreren Datenverkehrsrouting-Methoden gepaart mit der kontinuierlichen Überwachung der Endpunktintegrität und damit einher gehendes automatisches Failover bei einem Ausfall von Endpunkten. Ein Beschleunigungsfunktion etwa durch Caching oder Nutzung eines CDNs über den Azure-Backbone wie bei Front Door ist hier nicht gegeben. Das erreicht man aber z. B. mit Azure Content Delivery Network.
Azure Content Delivery Network
Unter einem Content Delivery Network (CDN) versteht man allgemein ein verteiltes Netzwerk mit Servern, über die Webinhalte effizienter als über das öffentliche Internet für Benutzer bereitgestellt werden können. CDN-Instanzen speichern zwischengespeicherte Inhalte auf Edge-Servern an POP-Standorten (Point of Presence), die sich in der Nähe der Endbenutzer befinden, um die Wartezeit zu verringern.
Azure CDN stellt Cloud-Architekten und Entwicklern eine globale Lösung zum performanten Übertragen von Inhalten mit hoher Bandbreite an Benutzer zur Verfügung. Dazu werden Inhalte auf POPs zwischengespeichert, die strategisch auf der ganzen Welt verteilt sind. Dank Verwendung verschiedener Netzwerkoptimierungen kann Azure CDN zudem auch dynamische Inhalte beschleunigen, die nicht zwischengespeichert werden können.
Trotzdem ist in erster Linie die Zwischenspeicherung eines CDN für dessen Funktionsweise maßgeblich. Zum einen um die Bereitstellung zu beschleunigen, aber auch um die Auslastung des Ursprungsservers (Origin) in Bezug auf statische Ressourcen wie Bilder, CSS-Dateien oder und Videos zu reduzieren. Bei einem CDN-Cache werden statische Ressourcen selektiv auf strategisch platzierten Servern gespeichert, die sich latenztechnisch „näher“ am Standort des anfragenden Clients befinden. Das funktioniert insbesondere deshalb so gut, weil der größte Teil des Datenverkehrs im World Wide Web statisch ist.
Eigentlich besteht Azure Content Delivery sogar aus vier verschiedenen Produkten, je nach dem welches Provider-Netzwerk für das Caching verwendet wird. Konkret sind das „Azure CDN Standard von Microsoft“, „Azure CDN Standard von Akamai“ und „Azure CDN Standard“ sowie „Azure CDN Premium“ von Verizon. Nur im ersten Fall nutzt Microsoft den eigenen Backbone und eigene POPs für das Caching und ist dann Bestandteil von Azure Front Door wie oben beschrieben. In einer Tabelle listet Microsoft die Unterschiede in den CDN-Features auf.
Azure Load Balancer
Schließlich gibt es noch den klassischen Azure Load Balancer. Er ist nur regional verfügbar, arbeitet auf Verbindungs-Ebene (Layer 4), kann in der kostenlos verfügbaren Stock Keeping Unit „SKU Basic“ nur mir Scale Sets oder Availability Sets genutzt werden und beherrscht dann auch keine SSL-Terminierung. Sowohl die Basic-SKU als auch die Standard-SKU können aber auf Wunsch automatisch im Kontext z. B. der Scale-Set-Erzeugung bereitgestellt werden.
Der Azure Load Balancer beherrscht aber selbstverständlich HTTP-Health-Probes, kann also sehr wohl zum lastausgeglichenen und/oder ausfallsicheren Betrieb von einfachen Websites verwendet werden, die auf Infrastruktur gehostet sind. Die Standard SKU kann im Backend-Pool auch einzelne VMs verwenden und kennt im Gegensatz zur Basic-SKU auch HTTPS-Health-Probes. Beide können Internet-Facing oder intern eingesetzt werden etwa für den Lastausgleich zischen Application-Tier und Datenbank-Tier.
Übrigens unterstützt Azure Load Balancer in Zukunft – das Feature ist im Moment als Preview eingestuft – auch regionsübergreifenden Lastenausgleich, was georedundante Hochverfügbarkeitsszenarien möglich macht.