Entwerfen einer geografisch verteilten Netzwerkarchitektur
In einer verteilten App muss sichergestellt werden, dass die Komponenten zuverlässig kommunizieren und Anforderungen an eine andere Komponente oder Region umgeleitet werden können, wenn ein Ausfall eintritt.
Wir haben unser Versandportal in Azure von Grund auf überarbeitet, damit es weniger anfällig für regionale Ausfälle wird. Wir möchten sicherstellen, dass für die Anwendung ein Failover auf Komponenten in einer sekundären Region ausgeführt wird, wenn die primäre Region nicht verfügbar ist. Das Failover sollte zu minimalen Unterbrechungen bei der Dienstbereitstellung für Benutzer*innen führen.
Hier erfahren Sie, wie Azure DNS, Traffic Manager, Front Door und Azure CDN die App-Architektur unseres Versandunternehmens stützen.
Azure DNS
Wie bereits erwähnt sind für die Implementierung von Azure DNS keine Änderungen erforderlich. Wir verwenden Azure DNS, um die Domänennamendatensätze zu hosten, die die App identifizieren.
Azure DNS bietet eine vollständige Namensauflösung über die Azure-Infrastruktur. Dieser Dienst ist grundsätzlich multiregional. Deshalb müssen Sie vorhandene Azure DNS-Konfigurationen nicht ändern, um das Feature in der neuen Architektur zu nutzen.
Die Azure DNS-SLA garantiert zudem, dass gültige DNS-Anforderungen in 100 % der Fälle eine Antwort von mindestens einem Azure DNS-Namenserver empfangen.
Auswählen eines Datenverkehrsrouters
Wir benötigen einen Dienst, der einen Lastenausgleich vornehmen und die Umleitung des Datenverkehrs über mehrere Regionen mit verteilten Webanwendungen hinweg durchführen kann.
Azure bietet verschiedene Dienste, die Datenverkehr zwischen Front-End-Komponenten weiterleiten können. Beachten Sie, dass Azure Application Gateway ersetzt werden muss, da es an eine einzelne Region gebunden ist. Wenn diese Region ausfällt, gibt es keine Region, in die umgeleitet werden kann.
Es gibt zwei Datenverkehrsrouter in Azure, die ein globales Routing zwischen mehreren Regionen durchführen können und nicht für Ausfälle in einer einzelnen Region anfällig sind:
- Azure Traffic Manager
- Azure Front Door
Nun werden diese Dienste näher erläutert, damit Sie den richtigen Router für Ihre Anwendung auswählen können.
Was ist Azure Traffic Manager?
Azure Traffic Manager ist ein globaler Lastenausgleich, der DNS-Datensätze verwendet, um Datenverkehr an Ziele in mehreren Azure-Regionen weiterzuleiten.
Sie können Traffic Manager so konfigurieren, dass alle Anforderungen an die primäre Region weitergeleitet werden und die Reaktionsfähigkeit der App Service-Instanz in dieser Region überwacht wird. Wenn die App Service-Instanz in der primären Region ausfällt, leitet Traffic Manager Benutzeranforderungen automatisch an die App Service-Instanz in der sekundären Region weiter. Durch diese Weiterleitung wird das Failover ausgeführt, das die Beständigkeit des Diensts sicherstellt. Dieser Ansatz wird als prioritätsbasierter Routingmodus bezeichnet.
Da Traffic Manager das DNS-System zum Weiterleiten von Datenverkehr verwendet, werden alle Protokolle und nicht nur der HTTP-Datenverkehr weitergeleitet. Traffic Manager kann Datenverkehr jedoch nicht auf Grundlage von HTTP-Eigenschaften weiterleiten oder filtern, wie z. B. Clientländercodes oder Benutzer-Agent-Header. Außerdem können keine TLS-Protokolle (Transport Layer Security) beendet werden, bei denen der Router Anforderungen entschlüsselt und die Antworten verschlüsselt, um die virtuellen App Service-Server zu entlasten. Wenn Sie eines dieser Features benötigen, müssen Sie Azure Front Door verwenden.
In Traffic Manager kommt eine hochgradig konfigurierbare Endpunktüberwachung zum Einsatz. Sie können beispielsweise das Protokoll, den Port, den Pfad, benutzerdefinierte Headereinstellungen, Bereiche für erwartete Statuscodes und die zulässige Fehleranzahl definieren. Durch die Endpunktüberwachung wissen Sie stets über die Integrität aller Komponenten der Anwendung Bescheid.
Was ist Azure Front Door?
Genau wie Traffic Manager ist Azure Front Door ein globaler Lastenausgleich. Der Unterschied zu Traffic Manager besteht jedoch darin, dass Azure Front Door auf der Anwendungsschicht (Schicht 7) agiert und HTTP- und HTTPS-Eigenschaften zum Filtern und Weiterleiten verwendet.
Mit Front Door sind viele Weiterleitungen möglich, die Traffic Manager nicht unterstützt. Sie können beispielsweise eine Weiterleitung anhand des Ländercodes Ihres Browsers durchführen. Mit Front Door können zudem TLS-Protokolle beendet werden.
Es gibt jedoch eine Ausnahme. Wenn Sie Datenverkehr für andere Protokolle als HTTP und HTTPS weiterleiten möchten, müssen Sie Traffic Manager verwenden.
Mit Front Door können Sie den verschiedenen Back-Ends, die das Überwachungsportal bilden, Prioritäten zuweisen. Mithilfe dieser Prioritäten kann Front Door Anforderungen nach Bedarf weiterleiten. Weisen Sie der primären Region Dienste mit der höchsten Priorität zu und der sekundären Region Dienste mit einer niedrigeren Priorität.
In Front Door werden Integritätstests durchgeführt, um den Integritätsstatus Ihrer Dienste zu überwachen. Wenn ein Ausfall eintritt, kann der Datenverkehr ordnungsgemäß weitergeleitet werden. Der prioritätsbasierte Routingmodus und die Endpunktüberwachung in Front Door ähneln den Features in Traffic Manager mit dem Unterschied, dass Integritätstests immer über HTTP durchgeführt werden.
Der gesamte Datenverkehr für die Benutzeroberfläche und die API des Onlineversandportals erfolgt über HTTPS. Dadurch können Azure Traffic Manager und Front Door im Wechsel eingesetzt werden. Zudem konfigurieren wir Front Door mit Prioritätszuweisungen für das Back-End.
Azure CDN
In der Architektur mit einer einzelnen Region wurde Azure CDN zum Zwischenspeichern der statischen Inhalte von Azure Blob Storage verwendet. Azure CDN ist ein globales Servernetzwerk, das statische Inhalte in Benutzernähe zwischenspeichert. Sie müssen diesen Dienst für Architekturen mit mehreren Regionen nicht anpassen. In der nächsten Lerneinheit erfahren Sie, was Sie dabei in Hinblick auf Ihr Azure Storage-Konto berücksichtigen müssen.