Unternehmenskritischer globaler HTTP-Eingang

Unternehmenskritische Anwendungen müssen ein hohes Niveau an Uptime bieten, auch wenn Netzwerkkomponenten nicht verfügbar oder beeinträchtigt sind. Beim Entwerfen von Eingang, Routing und Sicherheit für Webdatenverkehr können Sie die Kombination mehrerer Azure-Dienste in Betracht ziehen, um eine höhere Verfügbarkeit zu erzielen und einen Single Point of Failure zu vermeiden.

Wenn Sie sich für diesen Ansatz entscheiden, müssen Sie einen separaten Netzwerkpfad zu Ihren Anwendungsservern implementieren. Dabei muss jeder Pfad gesondert konfiguriert und getestet werden. Sie müssen die vollständigen Auswirkungen dieses Ansatzes sorgfältig prüfen.

In diesem Artikel wird ein Ansatz zur Unterstützung des globalen eingehenden HTTP-Datenverkehrs über Azure Front Door und Azure Application Gateway beschrieben. Dieser Ansatz kann zu Ihren Anforderungen passen, wenn Ihre Lösung Folgendes erfordert:

• Azure Front Door für globales Datenverkehrsrouting. Dies kann bedeuten, dass sich mehrere Instanzen Ihrer Anwendung in getrennten Azure-Regionen befinden oder dass Sie für alle globalen Benutzer*innen eine einzige Region nutzen.
• Web Application Firewall (WAF) zum Schutz Ihrer Anwendung, unabhängig vom Pfad, dem Ihr Datenverkehr folgt, um Ihre Ursprungsserver zu erreichen.

Das Zwischenspeichern am Netzwerkrand ist kein entscheidender Bestandteil der Anwendungsbereitstellung. Wenn das Zwischenspeichern wichtig ist, finden Sie unter Bereitstellung unternehmenskritischer globaler Inhalte einen alternativen Ansatz.

Vorgehensweise

Diese DNS-basierte Lastenausgleichslösung verwendet mehrere Azure Traffic Manager-Profile zum Überwachen von Azure Front Door. Im unwahrscheinlichen Fall eines Problems mit der Verfügbarkeit leitet Traffic Manager Datenverkehr über Application Gateway um.

Die Lösung enthält folgende Komponenten:

• Traffic Manager im Modus des prioritätsbasierten Routings weist zwei Endpunkte auf. Standardmäßig sendet Traffic Manager Anforderungen über Azure Front Door. Wenn Azure Front Door nicht verfügbar ist, bestimmt ein zweites Traffic Manager-Profil, wohin die Anforderung weitergeleitet wird. Das zweite Profil wird unten beschrieben.

• Azure Front Door verarbeitet den größten Teil Ihres Anwendungsdatenverkehrs und leitet ihn weiter. Azure Front Door leitet Datenverkehr an den entsprechenden Ursprungsanwendungsserver weiter und stellt den primären Pfad zu Ihrer Anwendung bereit. Die WAF von Azure Front Door schützt Ihre Anwendung vor gängigen Sicherheitsbedrohungen. Wenn Azure Front Door nicht verfügbar ist, wird der Datenverkehr automatisch über den sekundären Pfad umgeleitet.

• Traffic Manager im Modus des leistungsbasierten Routings weist einen Endpunkt für jede Application Gateway-Instanz auf. Dieser Traffic Manager sendet vom Standort des Clients Anforderungen an die Application Gateway-Instanz mit der besten Leistung.

• Application Gateway wird in jeder Region bereitgestellt und sendet Datenverkehr an die Ursprungsserver in dieser Region. Die WAF von Application Gateway schützt den gesamten Datenverkehr, der durch den sekundären Pfad fließt.

• Ihre Ursprungsanwendungsserver müssen jederzeit bereit sein, Datenverkehr von Azure Front Door und Azure Application Gateway zu akzeptieren.

Überlegungen

In den folgenden Abschnitten werden einige wichtige Überlegungen für diese Art von Architektur beschrieben. Sie sollten auch unternehmenskritische globale Webanwendungen auf andere wichtige Überlegungen und Nachteile überprüfen, wenn Sie Azure Front Door in einer unternehmenskritischen Lösung verwenden.

Traffic Manager-Konfiguration

Dieser Ansatz verwendet geschachtelte Traffic Manager-Profile, um prioritätsbasiertes und leistungsbasiertes Routing für den alternativen Datenverkehrspfad Ihrer Anwendung zu erreichen. In einem einfachen Szenario mit einem Ursprung in einer einzelnen Region benötigen Sie möglicherweise nur ein einzelnes Traffic Manager-Profil, das für die Verwendung von prioritätsbasiertem Routing konfiguriert ist.

Regionale Verteilung

Azure Front Door ist ein globaler Dienst, Application Gateway ist dagegen ein regionaler Dienst.

Die Übergabepunkte von Azure Front Door werden global bereitgestellt, und TCP- und TLS-Verbindungen enden am nächstgelegenen Übergabepunkt des Clients. Dieses Verhalten verbessert die Leistung Ihrer Anwendung. Wenn Clients hingegen eine Verbindung mit Application Gateway herstellen, enden ihre TCP- und TLS-Verbindungen an der Application Gateway-Instanz, die die Anforderung empfängt, unabhängig vom Ursprung des Datenverkehrs.

Verbindungen von Clients

Als globaler mehrinstanzenfähiger Dienst bietet Azure Front Door inhärenten Schutz vor einer Vielzahl von Bedrohungen. Azure Front Door akzeptiert nur gültigen HTTP- und HTTPS-Datenverkehr und keinen Datenverkehr mit anderen Protokollen. Microsoft verwaltet die öffentlichen IP-Adressen, die Azure Front Door für eingehende Verbindungen verwendet. Aufgrund dieser Merkmale kann Azure Front Door dazu beitragen, Ihren Ursprung vor verschiedenen Angriffstypen zu schützen. Zudem können Ihre Ursprünge so konfiguriert werden, dass sie Private Link-Konnektivität verwenden.

Im Gegensatz dazu ist Application Gateway ein internetbasierter Dienst mit einer dedizierten öffentlichen IP-Adresse. Sie müssen Ihr Netzwerk und Ihre Ursprungsserver vor einer Vielzahl von Angriffstypen schützen. Weitere Informationen finden Sie unter Ursprungssicherheit.

Private Link-Verbindungen mit Ursprungsservern

Azure Front Door Premium bietet Private Link-Konnektivität mit Ihren Ursprüngen, wodurch die öffentliche Oberfläche mit Internetzugang Ihrer Lösung verringert wird.

Wenn Sie Private Link verwenden, um eine Verbindung mit Ihren Ursprüngen herzustellen, sollten Sie einen privaten Endpunkt in Ihrem virtuellen Netzwerk bereitstellen. Konfigurieren Sie dann Application Gateway so, dass der private Endpunkt als Back-End für Ihre Anwendung verwendet wird.

Skalierung

Wenn Sie Application Gateway bereitstellen, stellen Sie dedizierte Computeressourcen für Ihre Lösung bereit. Wenn unerwartet große Datenmengen an Ihrem Application Gateway eingehen, können Probleme mit der Leistung oder Zuverlässigkeit auftreten.

Um dieses Risiko zu minimieren, überlegen Sie, wie Sie Ihre Application Gateway-Instanz skalieren. Verwenden Sie die automatische Skalierung, oder stellen Sie sicher, dass Sie die Instanz manuell so skaliert haben, dass sie den gesamten Datenverkehr verarbeiten kann, den Sie nach einem Failover möglicherweise empfangen.

Caching

Wenn Sie die Funktion zum Zwischenspeichern von Azure Front Door verwenden, müssen Sie beachten, dass Inhalte nicht mehr aus den Azure Front Door-Caches bereitgestellt werden, sobald Ihr Datenverkehr zum alternativen Pfad wechselt und Application Gateway verwendet.

Wenn für Ihre Lösung das Zwischenspeichern erforderlich ist, finden Sie unter Bereitstellung unternehmenskritischer globaler Inhalte einen alternativen Ansatz, bei dem ein Partner-CDN als Fallback für Azure Front Door verwendet wird.

Wenn Sie das Zwischenspeichern verwenden, es aber kein wesentlicher Bestandteil Ihrer Anwendungsbereitstellungsstrategie ist, überlegen Sie alternativ, ob Sie Ihre Ursprünge auf- oder hochskalieren können, um die erhöhte Last zu bewältigen, die durch die höhere Anzahl von Cachefehlern während eines Failovers verursacht wurde.

Kompromisse

Diese Art von Architektur ist besonders nützlich, wenn Ihr alternativer Datenverkehrspfad Funktionen wie Anforderungsverarbeitungsregeln, WAF und TLS-Auslagerung verwenden soll. Azure Front Door und Application Gateway bieten ähnliche Funktionen.

Es gibt jedoch Nachteile:

• Komplexität des Betriebs. Wenn Sie eine dieser Funktionen verwenden, müssen Sie sie sowohl in Azure Front Door als auch in Application Gateway konfigurieren. Wenn Sie beispielsweise eine Konfigurationsänderung an der WAF von Azure Front Door vornehmen, müssen Sie die gleiche Konfigurationsänderung auch auf die WAF von Application Gateway anwenden. Die Komplexität des Betriebs wird viel größer, wenn Sie zwei separate Systeme neu konfigurieren und testen müssen.

• Funktionsparität. Obwohl es Ähnlichkeiten zwischen den Funktionen gibt, die Azure Front Door und Application Gateway bieten, sind viele Funktionen nicht genau gleich. Beachten Sie diese Unterschiede, da sie sich auf die Bereitstellung der Anwendung basierend auf dem verfolgten Datenverkehrspfad auswirken können.

  Application Gateway bietet kein Zwischenspeichern. Weitere Informationen zu diesem Unterschied finden Sie unter Zwischenspeichern.

  Azure Front Door und Application Gateway sind unterschiedliche Produkte und weisen unterschiedliche Anwendungsfälle auf. Insbesondere bestehen Unterschiede bei der Bereitstellung der beiden Produkte in Azure-Regionen. Stellen Sie sicher, dass Sie die Details jedes Produkts und dessen Verwendung verstehen.

• Kosten: In der Regel müssen Sie in jeder Region, in der Sie einen Ursprung haben, eine Application Gateway-Instanz bereitstellen. Da jede Application Gateway-Instanz separat abgerechnet wird, können die Kosten stark steigen, wenn Sie Ursprünge in mehreren Regionen bereitgestellt haben.

  Wenn die Kosten ein wichtiger Faktor für Ihre Lösung sind, finden Sie unter Bereitstellung unternehmenskritischer globaler Inhalte einen alternativen Ansatz, bei dem ein Partner-CDN (Content Delivery Network) als Fallback für Azure Front Door verwendet wird. Einige CDNs rechnen Datenverkehr auf Verbrauchsbasis ab, sodass dieser Ansatz kostengünstiger sein kann. Sie können jedoch einige der übrigen Vorteile durch die Verwendung von Application Gateway für Ihre Lösung verlieren.

  Alternativ können Sie die Bereitstellung einer alternativen Architektur in Betracht ziehen, in der Traffic Manager Datenverkehr direkt an PaaS-Anwendungsdienste (Platform-as-a-Service) weiterleiten kann. Dadurch ist Application Gateway nicht erforderlich, und Ihre Kosten werden gesenkt. Sie können diesen Ansatz in Betracht ziehen, wenn Sie einen Dienst wie Azure App Service oder Azure Container Apps für Ihre Lösung verwenden. Wenn Sie jedoch diesen Ansatz verfolgen, müssen Sie mehrere wichtige Nachteile berücksichtigen:

  • WAF: Azure Front Door und Application Gateway bieten WAF-Funktionen. Wenn Sie Ihre Anwendungsdienste direkt im Internet verfügbar machen, können Sie Ihre Anwendung möglicherweise nicht mit einer WAF schützen.
  • TLS-Auslagerung: Azure Front Door und Application Gateway beenden TLS-Verbindungen. Ihre Anwendungsdienste müssen so konfiguriert sein, dass TLS-Verbindungen beendet werden.
  • Routing: Azure Front Door und Application Gateway führen Routing über mehrere Ursprünge oder Back-Ends durch, einschließlich pfadbasiertem Routing, und sie unterstützen komplexe Routingregeln. Wenn Ihre Anwendungsdienste direkt im Internet verfügbar gemacht werden, können Sie kein Datenverkehrsrouting durchführen.

Nächste Schritte

Überprüfen Sie das Szenario für die globale Inhaltsbereitstellung, um zu verstehen, ob es auf Ihre Lösung zutrifft.