Globale Routingredundanz für unternehmenskritische Webanwendungen

Von Bedeutung

Das Entwerfen von Redundanzimplementierungen, die globale Plattformausfälle für eine unternehmenskritische Architektur behandeln, kann komplex und kostspielig sein. Aufgrund der potenziellen Probleme, die mit diesem Design auftreten können, sollten Sie die Kompromisse sorgfältig berücksichtigen.

In den meisten Fällen benötigen Sie die in diesem Artikel beschriebene Architektur nicht.

Unternehmenskritische Systeme bemühen sich, einzelne Fehlerpunkte zu minimieren, indem redundanz- und Selbstheilungsfunktionen in der Lösung so weit wie möglich erstellt werden. Jeder einheitliche Einstiegspunkt des Systems kann als Fehlerpunkt betrachtet werden. Wenn diese Komponente einen Ausfall erlebt, ist das gesamte System für den Benutzer offline. Bei der Auswahl eines Routingdiensts ist es wichtig, die Zuverlässigkeit des Diensts selbst zu berücksichtigen.

In der Basisarchitektur für eine unternehmenskritische Anwendung wurde Azure Front Door aufgrund seiner hohen Verfügbarkeitsvereinbarungen auf Serviceebene (SLA) und einem umfangreichen Featuresatz ausgewählt:

• Weiterleitung des Datenverkehrs an mehrere Regionen in einem Aktiv-Aktiv-Modell
• Transparentes Failover mit TCP Anycast
• Bereitstellen statischer Inhalte über Edge-Knoten mithilfe integrierter Content Delivery Networks (CDNs)
• Blockieren des nicht autorisierten Zugriffs mit integrierter Webanwendungsfirewall

Weitere Informationen zu den Funktionen von Azure Front Door finden Sie unter Beschleunigen und Sichern Ihrer Webanwendung mit Azure Front Door.

Azure Front Door ist so konzipiert, dass sie nicht nur für unsere externen Kunden, sondern auch für mehrere Eigenschaften in Microsoft die größtmögliche Resilienz und Verfügbarkeit bietet. Azure Front Door-Funktionen sind mehr als ausreichend, um die meisten geschäftlichen Anforderungen zu erfüllen, jedoch sind bei jedem verteilten System Fehler zu erwarten. Keine Komponente oder kein System ist unfehlbar. Microsoft bietet einen branchenführenden Service Level Agreement (SLA) für Azure Front Door an. Auch wenn ein anderer Anbieter eine SLA mit einer Verfügbarkeit von 100% bietet, ist es wichtig zu beachten, dass dies keine Garantie für null Ausfallzeiten ist und dass SLAs in der Regel Dienstguthaben im Falle eines Ausfalls bereitstellen.

Wenn die Geschäftsanforderungen bei einem Ausfall eine höhere zusammengesetzte SLO oder null Ausfallzeiten erfordern, müssen Sie sich auf mehrere alternativen Datenverkehrseingangspfad verlassen. Viele große Organisationen und bekannte Websites verwenden diesen Ansatz, um die bestmögliche Verfügbarkeit sicherzustellen und die Lieferleistung zu optimieren. Das Streben nach einem höheren SLO ist jedoch mit erheblichen Kosten und Betriebsaufwand verbunden und kann Ihre Gesamtzuverlässigkeit senken. Berücksichtigen Sie sorgfältig die Kompromisse und potenziellen Probleme, die der alternative Pfad in anderen Komponenten auf dem kritischen Weg einführen könnte. Auch wenn die Auswirkungen der Nichtverfügbarkeit erheblich sind, kann die Komplexität den Nutzen überwiegen.

Ein Ansatz besteht darin, einen sekundären Pfad mit alternativen Diensten zu definieren, die nur aktiv werden, wenn Azure Front Door nicht verfügbar ist. Die Featureparität mit Azure Front Door sollte nicht als eine harte Anforderung behandelt werden. Priorisieren Sie Features, die Sie unbedingt für Geschäftskontinuitätszwecke benötigen, auch wenn sie potenziell in einer begrenzten Kapazität ausgeführt werden.

In diesem Artikel werden einige Strategien für das globale Routing mithilfe von Azure Traffic Manager als alternativer Router in Situationen beschrieben, in denen Azure Front Door nicht verfügbar ist.

Vorgehensweise

Dieses Architekturdiagramm zeigt einen allgemeinen Ansatz mit mehreren redundanten Datenverkehrspfaden.

Mit diesem Ansatz werden wir mehrere Komponenten einführen und Anleitungen bereitstellen, die erhebliche Änderungen vornehmen, die der Bereitstellung Ihrer Webanwendung(en) zugeordnet sind:

1. Azure Traffic Manager leitet Datenverkehr an Azure Front Door oder an den von Ihnen ausgewählten alternativen Dienst weiter.

   Azure Traffic Manager ist ein DNS-basierter globaler Lastenausgleich. Der CNAME-Eintrag Ihrer Domäne verweist auf Den Traffic Manager, der das Ziel basierend auf der Konfiguration der Routingmethode bestimmt. Durch die Verwendung des Prioritätsroutings wird der Datenverkehr standardmäßig über Azure Front Door geleitet. Der Traffic Manager kann den Datenverkehr automatisch auf Ihren alternativen Pfad umschalten, wenn Azure Front Door nicht verfügbar ist.

   Von Bedeutung

   Diese Lösung mindert Risiken, die mit Ausfällen in Azure Front Door oder anderen Anbietern verbunden sind, aber es ist anfällig für Azure Traffic Manager-Ausfälle als globaler Fehlerpunkt. Weitere Informationen finden Sie unter Verfügbarkeit von Azure Traffic Manager.

   Sie können auch ein anderes globales Routingsystem für Datenverkehr verwenden, z. B. einen globalen Lastenausgleich. Der Traffic Manager funktioniert jedoch für viele Situationen gut.

2. Sie haben zwei Eingangspfade:

   • Azure Front Door bietet den primären Pfad und bearbeitet und leitet den gesamten Anwendungsdatenverkehr weiter.

   • Ein anderer Router wird als Sicherung für Azure Front Door verwendet. Der Verkehr fließt nur durch diesen sekundären Weg, wenn Front Door nicht verfügbar ist.

   Der spezifische Dienst, den Sie für den sekundären Router auswählen, hängt von vielen Faktoren ab. Sie können azure-native Dienste oder Dienste von Drittanbietern verwenden. In diesen Artikeln bieten wir, wo möglich, Azure-native Optionen an, um die betriebliche Komplexität der Lösung nicht zu erhöhen. Wenn Sie Dienste von Drittanbietern verwenden, müssen Sie mehrere Steuerungsebenen verwenden, um Ihre Lösung zu verwalten.

3. Ihre Ursprungsanwendungsserver müssen bereit sein, datenverkehr von beiden Diensten zu akzeptieren. Überlegen Sie, wie Sie den Datenverkehr zu Ihrem Ursprung sichern und welche Zuständigkeiten Azure Front Door und andere upstream-Dienste bereitstellen. Stellen Sie sicher, dass Ihre Anwendung Datenverkehr verarbeiten kann, egal von welchem Pfad der Datenverkehr fließt.

Kompromisse

Obwohl diese Risikominderungsstrategie die Anwendung während plattformübergreifender Ausfälle verfügbar machen kann, gibt es einige erhebliche Kompromisse. Sie sollten die potenziellen Vorteile gegen bekannte Kosten abwägen und eine fundierte Entscheidung darüber treffen, ob die Vorteile diese Kosten wert sind.

• Finanzielle Kosten: Wenn Sie mehrere redundante Pfade für Ihre Anwendung bereitstellen, müssen Sie die Kosten für die Bereitstellung und Ausführung der Ressourcen berücksichtigen. Wir bieten zwei Beispielszenarien für unterschiedliche Anwendungsfälle, von denen jedes ein anderes Kostenprofil aufweist.

• Betriebskomplexität: Jedes Mal, wenn Sie Ihrer Lösung zusätzliche Komponenten hinzufügen, erhöhen Sie ihren Verwaltungsaufwand. Jede Änderung an einer Komponente kann sich auf andere Komponenten auswirken.

  Angenommen, Sie entscheiden sich für die Verwendung der neuen Funktionen von Azure Front Door. Sie müssen überprüfen, ob Ihr alternativer Datenverkehrspfad auch eine gleichwertige Funktion bietet. Andernfalls müssen Sie entscheiden, wie der Unterschied im Verhalten zwischen den beiden Verkehrspfaden behandelt werden soll. In realen Anwendungen können diese Komplexitäten eine hohe Kosten haben und können ein großes Risiko für die Stabilität Ihres Systems darstellen.

• Leistung: Für diesen Entwurf sind zusätzliche CNAME-Lookups während der Namensauflösung erforderlich. In den meisten Anwendungen ist dies kein wesentliches Problem, Sie sollten jedoch bewerten, ob die Anwendungsleistung durch die Einführung zusätzlicher Ebenen in Ihren Eingangspfad beeinflusst wird.

• Opportunitätskosten: Das Entwerfen und Implementieren redundanter Eingangspfade erfordert eine erhebliche Engineering-Investition, was letztendlich zu einem Kostenaufwand für die Entwicklung von Features und anderen Plattformverbesserungen kommt.

Warnung

Wenn Sie nicht vorsichtig sind, wie Sie eine komplexe Hochverfügbarkeitslösung entwerfen und implementieren, können Sie Ihre Verfügbarkeit sogar noch schlimmer machen. Wenn Sie die Anzahl der Komponenten in Ihrer Architektur erhöhen, wird die Anzahl der Fehlerpunkte erhöht. Es bedeutet auch, dass Sie ein höheres Maß an betrieblicher Komplexität haben. Wenn Sie zusätzliche Komponenten hinzufügen, müssen alle vorgenommenen Änderungen sorgfältig überprüft werden, um zu verstehen, wie sich dies auf Ihre Gesamtlösung auswirkt.

Verfügbarkeit von Azure Traffic Manager

Azure Traffic Manager ist ein zuverlässiger Dienst mit einem branchenführenden SLA, aber kein Datenverkehrsverwaltungsdienst kann 100% Verfügbarkeit garantieren. Wenn Traffic Manager nicht verfügbar ist, können Ihre Benutzer möglicherweise nicht auf Ihre Anwendung zugreifen, auch wenn Azure Front Door und Ihr alternativer Dienst verfügbar sind. Es ist wichtig zu planen, wie Ihre Lösung unter diesen Umständen weiterhin funktioniert.

Der Datenverkehrs-Manager gibt zwischengespeicherte DNS-Antworten zurück. Wenn die Lebensdauer (TTL) auf Ihren DNS-Einträgen das Zwischenspeichern zulässt, sind kurze Ausfälle des Traffic-Managers eventuell unproblematisch. Das liegt daran, dass nachgeschaltete DNS-Resolver möglicherweise eine vorherige Antwort zwischengespeichert haben. Sie sollten längere Ausfälle planen. Möglicherweise können Sie Ihre DNS-Server manuell neu konfigurieren, um Benutzer an Azure Front Door zu leiten, wenn Traffic Manager nicht verfügbar ist.

Konsistente Verkehrsführung

Es ist wichtig, die Funktionen und Features von Azure Front Door zu verstehen, die Sie verwenden und darauf vertrauen, wenn Sie auch einen anderen Dienst verwenden werden. Wenn Sie den alternativen Dienst auswählen, entscheiden Sie die minimalen Funktionen, die Sie benötigen, und lassen Sie andere Features aus, wenn sich Ihre Lösung in einem beeinträchtigten Modus befindet.

Bei der Planung eines alternativen Verkehrspfads sollten Sie folgende wichtige Fragen berücksichtigen:

• Verwenden Sie die Zwischenspeicherungsfunktionen von Azure Front Door? Wenn die Zwischenspeicherung nicht verfügbar ist, können Ihre Ursprungsserver mit Ihrem Datenverkehr Schritt halten?
• Verwenden Sie das Azure Front Door-Regelmodul, um benutzerdefinierte Routinglogik auszuführen oder Anforderungen neu zu schreiben?
• Verwenden Sie die Azure Front Door-Webanwendungsfirewall (WAF), um Ihre Anwendungen zu schützen?
• Beschränken Sie den Datenverkehr basierend auf IP-Adresse oder geografischer Lage?
• Wer stellt Ihre TLS-Zertifikate aus und verwaltet sie?
• Wie schränken Sie den Zugriff auf Ihre Ursprungsanwendungsserver ein, um sicherzustellen, dass er über Azure Front Door kommt? Verwenden Sie private Links, oder verwenden Sie öffentliche IP-Adressen mit Diensttags und Bezeichnerheadern?
• Akzeptieren Ihre Anwendungsserver Datenverkehr von anderen Orten als Azure Front Door? Welche Protokolle akzeptieren sie, wenn sie dies tun?
• Verwenden Ihre Clients die HTTP/2-Unterstützung von Azure Front Door?

Web Application Firewall (WAF)

Wenn Sie die WAF von Azure Front Door verwenden, um Ihre Anwendung zu schützen, überlegen Sie, was passiert, wenn der Datenverkehr nicht über Azure Front Door geht.

Wenn Ihr alternativer Pfad auch eine WAF bereitstellt, sollten Sie die folgenden Fragen in Betracht ziehen:

• Kann sie auf die gleiche Weise wie Ihre Azure Front Door WAF konfiguriert werden?
• Muss es unabhängig abgestimmt und getestet werden, um die Wahrscheinlichkeit falsch positiver Erkennungen zu verringern?

Warnung

Sie könnten sich entscheiden, WAF nicht für ihren alternativen Eingangspfad zu verwenden. Dieser Ansatz kann berücksichtigt werden, um das Zuverlässigkeitsziel der Anwendung zu unterstützen. Dies ist jedoch keine gute Sicherheitspraxis, und es wird nicht empfohlen.

Berücksichtigen Sie den Kompromiss bei der Annahme von Datenverkehr aus dem Internet ohne Überprüfungen. Wenn ein Angreifer einen nicht geschützten sekundären Datenverkehrspfad zu Ihrer Anwendung erkennt, sendet er möglicherweise bösartigen Datenverkehr über Ihren sekundären Pfad, auch wenn der primäre Pfad einen WAF enthält.

Es ist am besten, alle Pfade zu Ihren Anwendungsservern zu sichern.

Zusätzliche Überlegungen für hohe Verfügbarkeit

Wenn Sie eine unternehmenskritische Webarchitektur entwerfen, gibt es viele Faktoren, die sich auf die Verfügbarkeit und Leistung Ihrer Anwendung auswirken können. Viele dieser Faktoren gehen über die Konfiguration und Funktionen von Azure Front Door hinaus und beziehen sich stattdessen auf das gesamte Ökosystem und das Lösungsdesign.

Domänennamen und DNS

Ihre unternehmenskritische Anwendung sollte einen benutzerdefinierten Domänennamen verwenden. Sie steuern, wie Datenverkehr zu Ihrer Anwendung fließt, und Sie reduzieren die Abhängigkeiten von einem einzelnen Anbieter.

Außerdem empfiehlt es sich, einen qualitativ hochwertigen und robusten DNS-Dienst für Ihren Domänennamen wie Azure DNS zu verwenden. Wenn die DNS-Server Ihres Domänennamens nicht verfügbar sind, können Benutzer Ihren Dienst nicht erreichen.

Es wird empfohlen, dass Sie mehrere DNS-Resolver verwenden, um die Gesamtresilienz noch weiter zu erhöhen.

CNAME-Verkettung

Lösungen, die Traffic Manager, Azure Front Door und andere Dienste kombinieren, verwenden einen mehrschichtigen DNS-CNAME-Auflösungsprozess, auch als CNAME-Verkettung bezeichnet. Wenn Sie beispielsweise Ihre eigene benutzerdefinierte Domäne auflösen, werden möglicherweise fünf oder mehr CNAME-Einträge angezeigt, bevor eine IP-Adresse zurückgegeben wird.

Das Hinzufügen zusätzlicher Links zu einer CNAME-Kette kann sich auf die Leistung der DNS-Namensauflösung auswirken. DNS-Antworten werden jedoch in der Regel zwischengespeichert, wodurch die Leistungseinbußen reduziert werden.

TLS-Zertifikate

Für eine unternehmenskritische Anwendung wird empfohlen, ihre eigenen TLS-Zertifikate anstelle der von Azure Front Door bereitgestellten verwalteten Zertifikate bereitzustellen und zu verwenden. Sie reduzieren die Anzahl potenzieller Probleme mit dieser komplexen Architektur.

Hier sind einige Vorteile:

• Um verwaltete TLS-Zertifikate auszustellen und zu erneuern, überprüft Azure Front Door Ihren Besitz der Domäne. Bei der Domänenüberprüfung wird davon ausgegangen, dass die CNAME-Einträge Ihrer Domäne direkt auf Azure Front Door verweisen. Aber diese Annahme ist oft nicht richtig. Das Ausstellen und Erneuern von verwalteten TLS-Zertifikaten auf Azure Front Door funktioniert möglicherweise nicht reibungslos, und Sie erhöhen das Risiko von Ausfällen aufgrund von TLS-Zertifikatproblemen.

• Selbst wenn Ihre anderen Dienste verwaltete TLS-Zertifikate bereitstellen, können sie möglicherweise den Domänenbesitz nicht überprüfen.

• Wenn jeder Dienst unabhängig seine eigenen verwalteten TLS-Zertifikate erhält, kann es Probleme geben. Benutzer erwarten z. B. möglicherweise nicht, dass unterschiedliche TLS-Zertifikate von verschiedenen Behörden oder mit unterschiedlichen Ablaufdaten oder Fingerabdrucken angezeigt werden.

Es gibt jedoch zusätzliche Vorgänge im Zusammenhang mit der Verlängerung und Aktualisierung Ihrer Zertifikate, bevor sie ablaufen.

Ursprungssicherheit

Wenn Sie Ihren Ursprung so konfigurieren , dass nur Datenverkehr über Azure Front Door akzeptiert wird, erhalten Sie Schutz vor Layer 3- und Layer 4-DDoS-Angriffen. Azure Front Door reagiert nur auf gültigen HTTP-Datenverkehr, was auch dazu beiträgt, Ihre Exposition gegenüber vielen protokollbasierten Bedrohungen zu verringern. Wenn Sie Ihre Architektur so ändern, dass alternative Eingangspfade zulässig sind, müssen Sie bewerten, ob Sie versehentlich die Exposition Ihres Ursprungs gegenüber Bedrohungen erhöht haben.

Wenn Sie private Verknüpfung verwenden, um eine Verbindung von Azure Front Door mit Ihrem Ursprungsserver herzustellen, wie fließt der Datenverkehr über Ihren alternativen Pfad? Können Sie private IP-Adressen verwenden, um auf Ihre Ursprünge zuzugreifen, oder müssen Sie öffentliche IP-Adressen verwenden?

Wenn Ihr Ursprung das Azure Front Door-Diensttag und den X-Azure-FDID-Header verwendet, um zu überprüfen, ob Datenverkehr über Azure Front Door fließt, sollten Sie überlegen, wie Ihre Ursprünge neu konfiguriert werden können, um zu überprüfen, ob der Datenverkehr über einen Ihrer gültigen Pfade fließt. Sie müssen prüfen, ob Sie Ihren Ursprung nicht versehentlich für Datenverkehr über andere Pfade geöffnet haben, auch für Datenverkehr von Azure Front Door-Profilen anderer Kunden.

Wenn Sie Ihre Ursprungssicherheit planen, überprüfen Sie, ob der alternative Datenverkehrspfad auf der Bereitstellung dedizierter öffentlicher IP-Adressen basiert. Dies kann einen manuell ausgelösten Prozess benötigen, um den Sicherungspfad online zu bringen.

Wenn es dedizierte öffentliche IP-Adressen gibt, überlegen Sie, ob Sie Azure DDoS Protection implementieren sollten, um das Risiko von Denial-of-Service-Angriffen auf Ihre Ursprünge zu verringern. Überlegen Sie außerdem, ob Sie Azure Firewall oder eine andere Firewall implementieren müssen, die Sie vor einer Vielzahl von Netzwerkbedrohungen schützt. Möglicherweise benötigen Sie auch mehr Angriffserkennungsstrategien. Diese Steuerelemente können wichtige Elemente in einer komplexeren Mehrpfadarchitektur sein.

Gesundheitsmodellierung

Eine unternehmenskritische Entwurfsmethodik erfordert ein Systemgesundheitsmodell, das umfassende Beobachtbarkeit der Lösung und ihrer Komponenten ermöglicht. Wenn Sie mehrere Datenverkehrseingangspfade verwenden, müssen Sie die Integrität der einzelnen Pfade überwachen. Wenn Ihr Datenverkehr an den sekundären Eingangspfad umgeleitet wird, sollte Ihr Integritätsmodell die Tatsache widerspiegeln, dass das System weiterhin betriebsbereit ist, aber in einem beeinträchtigten Zustand ausgeführt wird.

Fügen Sie die folgenden Fragen in das Design Ihres Gesundheitsmodells ein.

• Wie überwachen die verschiedenen Komponenten Ihrer Lösung die Integrität der nachgeschalteten Komponenten?
• Wann sollten Gesundheitsüberwachungen nachgeschaltete Komponenten als ungesund gelten lassen?
• Wie lange dauert es, bis ein Ausfall erkannt wird?
• Nachdem ein Ausfall erkannt wurde, wie lange dauert es, bis der Datenverkehr über einen alternativen Pfad weitergeleitet wird?

Es gibt mehrere globale Lastenausgleichslösungen, mit denen Sie den Zustand von Azure Front Door überwachen und ein automatisches Failover auf eine Sicherungsplattform auslösen können, wenn ein Ausfall auftritt. Azure Traffic Manager eignet sich in den meisten Fällen. Mit Traffic Manager konfigurieren Sie die Endpunktüberwachung , um nachgeschaltete Dienste zu überwachen, indem Sie angeben, welche URL überprüft werden soll, wie häufig diese URL überprüft werden soll, und wann der nachgeschaltete Dienst nicht ordnungsgemäß ist, basierend auf Prüfantworten. Im Allgemeinen desto kürzer ist das Intervall zwischen den Prüfungen, desto weniger Zeit dauert es, bis Traffic Manager den Datenverkehr über einen alternativen Pfad leitet, um Ihren Ursprungsserver zu erreichen.

Wenn Azure Front Door nicht verfügbar ist, beeinflussen mehrere Faktoren die Zeitspanne, die sich der Ausfall auf Ihren Datenverkehr auswirkt, einschließlich:

• Die Gültigkeitsdauer (TTL) Ihrer DNS-Einträge.
• Wie häufig der Traffic Manager seine Gesundheitsprüfungen ausführt.
• nach wie vielen fehlgeschlagenen Tests Traffic Manager den Datenverkehr umleiten soll.
• Wie lange Clients und upstream-DNS-Server die DNS-Antworten von Traffic Manager zwischenspeichern.

Sie müssen auch bestimmen, welche dieser Faktoren in Ihrem Steuerelement enthalten sind und ob upstream-Dienste, die sich über Ihr Steuerelement hinausgehen, auf die Benutzererfahrung auswirken können. Selbst wenn Sie z. B. niedrige TTL für Ihre DNS-Einträge verwenden, können upstream-DNS-Caches für längere Zeit veraltete Antworten bereitstellen, als sie sollten. Dieses Verhalten kann die Auswirkungen eines Ausfalls noch verschlimmern oder so aussehen, als ob Ihre Anwendung nicht verfügbar ist, auch wenn Traffic Manager bereits zum Senden von Anforderungen an den alternativen Datenverkehrspfad gewechselt ist.

Tipp

Unternehmenskritische Lösungen erfordern nach Möglichkeit automatisierte Failoveransätze. Manuelle Failoverprozesse gelten als langsam, damit die Anwendung reaktionsfähig bleibt.

Verweisen Sie auf: Missionskritischer Designbereich: Gesundheitsmodellierung

Bereitstellung ohne Ausfallzeiten

Wenn Sie planen, wie sie eine Lösung mit redundantem Eingangspfad betreiben, sollten Sie auch planen, wie Sie Ihre Dienste bereitstellen oder konfigurieren, wenn sie beeinträchtigt werden. Für die meisten Azure-Dienste gelten SLAs für die Betriebszeit des Diensts selbst und nicht für Verwaltungsvorgänge oder Bereitstellungen. Überlegen Sie, ob Ihre Bereitstellungs- und Konfigurationsprozesse ausfallsicher gegenüber Dienstausfällen gemacht werden müssen.

Sie sollten auch die Anzahl der unabhängigen Steuerungsebenen berücksichtigen, mit denen Sie interagieren müssen, um Ihre Lösung zu verwalten. Wenn Sie Azure-Dienste verwenden, bietet Azure Resource Manager eine einheitliche und konsistente Kontrollebene. Wenn Sie jedoch einen Drittanbieterdienst zum Weiterleiten des Datenverkehrs verwenden, müssen Sie möglicherweise eine separate Kontrollebene verwenden, um den Dienst zu konfigurieren, wodurch weitere Betriebskomplexität eingeführt wird.

Warnung

Die Verwendung mehrerer Steuerebenen führt zu Komplexität und Risiko für Ihre Lösung. Jeder Unterschied erhöht die Wahrscheinlichkeit, dass jemand versehentlich eine Konfigurationseinstellung verpasst oder verschiedene Konfigurationen auf redundante Komponenten anwendet. Stellen Sie sicher, dass Ihre betrieblichen Verfahren dieses Risiko mindern.

Weitere Informationen finden Sie unter : Unternehmenskritischer Entwurfsbereich: Bereitstellung ohne Ausfallzeiten

Fortlaufende Validierung

Für eine unternehmenskritische Lösung müssen Ihre Testpraktiken überprüfen, ob Ihre Lösung Ihre Anforderungen erfüllt, unabhängig vom Pfad, über den Ihr Anwendungsdatenverkehr fließt. Berücksichtigen Sie jeden Teil der Lösung und wie Sie ihn für jeden Ausfalltyp testen.

Stellen Sie sicher, dass Ihre Testprozesse die folgenden Elemente enthalten:

• Können Sie überprüfen, ob der Datenverkehr ordnungsgemäß über den alternativen Pfad umgeleitet wird, wenn der primäre Pfad nicht verfügbar ist?
• Können beide Pfade den zu erwartenden Datenverkehr in der Produktion bewältigen?
• Sind beide Pfade angemessen gesichert, um im Status „Heruntergestuft“ das Öffnen oder Offenlegen von Sicherheitsrisiken zu vermeiden?

Verweisen Sie auf: Missionskritischer Gestaltungsbereich: Kontinuierliche Validierung

Häufige Szenarien

Nachfolgend finden Sie häufige Szenarien, in denen dieses Design verwendet werden kann:

• Die globale Inhaltsbereitstellung gilt häufig für statische Inhaltsbereitstellungen, Medien und hochskalige E-Commerce-Anwendungen. In diesem Szenario ist die Zwischenspeicherung ein wichtiger Bestandteil der Lösungsarchitektur, und Fehler beim Zwischenspeichern können zu erheblich beeinträchtigter Leistung oder Zuverlässigkeit führen.

• Der globale HTTP-Ingress gilt häufig für unternehmenskritische dynamische Anwendungen und APIs. In diesem Szenario muss der Datenverkehr zuverlässig und effizient an den Ursprungsserver weitergeleitet werden. Häufig ist ein WAF ein wichtiges Sicherheitssteuerelement, das in diesen Lösungen verwendet wird.

Warnung

Wenn Sie beim Entwerfen und Implementieren einer komplexen Lösung mit mehreren Komponenten nicht sorgfältig vorgehen, können Sie die Verfügbarkeit sogar verschlechtern. Wenn Sie die Anzahl der Komponenten in Ihrer Architektur erhöhen, wird die Anzahl der Fehlerpunkte erhöht. Es bedeutet auch, dass Sie ein höheres Maß an betrieblicher Komplexität haben. Wenn Sie zusätzliche Komponenten hinzufügen, müssen alle vorgenommenen Änderungen sorgfältig überprüft werden, um zu verstehen, wie sich dies auf Ihre Gesamtlösung auswirkt.

Beitragende

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautoren:

• Dave Burkhardt | Principal Program Manager, Azure Front Door
• John Downs | Leitender Softwareentwickler
• Priyanka Wilkins | Prinzipalinhaltsentwickler

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Überprüfen Sie die globalen HTTP-Eingangs - und globalen Inhaltsübermittlungsszenarien , um zu verstehen, ob sie für Ihre Lösung gelten.