Globale Routingredundanz für unternehmenskritische Webanwendungen

Wichtig

Der Entwurf von Redundanzimplementierungen, die globale Plattformausfälle für eine unternehmenskritische Architektur bewältigen, kann komplex und kostspielig sein. Aufgrund der potenziellen Probleme, die bei diesem Entwurf auftreten können, sollten Sie die Kompromisse sorgfältig berücksichtigen.

In den meisten Situationen benötigen Sie die in diesem Artikel beschriebene Architektur nicht.

Bei unternehmenskritischen Systemen wird versucht, Single Points of Failure zu minimieren, indem Redundanz und Selbstreparaturfunktionen so weit wie möglich in die Lösung integriert werden. Jeder einheitliche Einstiegspunkt des Systems kann als Fehlerquelle betrachtet werden. Wenn diese Komponente ausfällt, 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 Baselinearchitektur für eine geschäftskritische Anwendung wurde Azure Front Door aufgrund der Vereinbarungen zum Servicelevel (SLA) für hohe Uptime und des umfangreichen Funktionsumfangs ausgewählt:

• Weiterleitung des Datenverkehrs an mehrere Regionen in einem Aktiv-Aktiv-Modell
• Transparentes Failover mit TCP Anycast
• Bereitstellung statischer Inhalte von Edgeknoten mit integrierten Content Delivery Networks (CDNs)
• Blockieren von unbefugtem Zugriff mit integrierter Web Application Firewall

Front Door wurde entwickelt, um ein Höchstmaß an Resilienz und Verfügbarkeit zu gewährleisten, und zwar nicht nur für unsere externen Kunden, sondern auch für mehrere Unternehmen von Microsoft. Weitere Informationen zu den Funktionen von Front Door finden Sie unter Beschleunigen und Schützen Ihrer Webanwendung mit Azure Front Door.

Die Front Door-Funktionen sind mehr als ausreichend, um die meisten geschäftlichen Anforderungen zu erfüllen, aber bei jedem verteilten System müssen Sie mit Ausfällen rechnen. Wenn die Geschäftsanforderungen bei einem Ausfall eine höhere zusammengesetzte SLO oder null Ausfallzeiten erfordern, müssen Sie sich auf einen alternativen Datenverkehrseingangspfad verlassen. Das Verfolgen einer höheren SLO ist jedoch mit erheblichen Kosten und betrieblichem Mehraufwand verbunden und kann Ihre Gesamtzuverlässigkeit verringern. Berücksichtigen Sie sorgfältig die Kompromisse und potenziellen Probleme, die der alternative Pfad in anderen Komponenten auf dem kritischen Pfad mit sich bringen könnte. Selbst 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, der nur aktiv wird, wenn Azure Front Door nicht verfügbar ist. Featureparität mit Front Door sollte nicht als zwingende Voraussetzung betrachtet werden. Priorisieren Sie Features, die Sie für die Geschäftskontinuität unbedingt benötigen, auch wenn diese möglicherweise nur in begrenztem Umfang zur Verfügung stehen.

Ein weiterer Ansatz ist die Verwendung von Drittanbietertechnologien für das globale Routing. Dieser Ansatz erfordert eine Aktiv-Aktiv-Multicloudbereitstellung mit Skalierungseinheiten, die über mindestens zwei Cloudanbieter gehostet werden. Auch wenn Azure effektiv in andere Cloudplattformen integriert werden kann, ist dieser Ansatz aufgrund der betrieblichen Komplexität der verschiedenen Cloudplattformen nicht zu empfehlen.

In diesem Artikel werden einige Strategien für das globale Routing mit Azure Traffic Manager als alternativem 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 mehrere Komponenten eingeführt und Leitfäden bereitgestellt die die Bereitstellung Ihrer Webanwendung(en) erheblich verändern werden:

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 Lastenausgleichsdienst. Der CNAME-Eintrag Ihrer Domäne verweist auf Traffic Manager, der das Ziel basierend auf der Konfiguration der Routingmethode bestimmt. Die Verwendung des prioritätsbasierten Routings bewirkt, dass Datenverkehr standardmäßig über Azure Front Door fließt. Traffic Manager kann den Datenverkehr automatisch auf Ihren alternativen Pfad umstellen, wenn Azure Front Door nicht verfügbar ist.

   Wichtig

   Diese Lösung mindert die Risiken, die mit Ausfällen von Azure Front Door verbunden sind, aber sie ist anfällig für Ausfälle von Azure Traffic Manager als globale Fehlerquelle.

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

2. Sie verfügen über zwei Eingangspfade:

   • Azure Front Door stellt den primären Pfad und die Prozesse bereit und leitet den gesamten Datenverkehr Ihrer Anwendung weiter.

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

   Welchen Dienst Sie genau für den sekundären Router auswählen, hängt von vielen Faktoren ab. Sie können native Azure-Dienste oder Dienste von Drittanbietern verwenden. In diesen Artikeln werden native Azure-Optionen bereitgestellt, um eine zusätzliche betriebliche Komplexität der Lösung zu vermeiden. 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 Datenverkehr an Ihren Ursprung schützen und welche Aufgaben Front Door und andere Upstream-Dienste übernehmen. Vergewissern Sie sich, dass Ihre Anwendung den Datenverkehr von jedem Pfad aus verarbeiten kann, über den Ihr Datenverkehr fließt.

Kompromisse

Diese Risikominderungstrategie kann zwar dazu führen, dass die Anwendung bei Plattformausfällen verfügbar ist, es gibt jedoch einige erhebliche Kompromisse. Sie sollten den potenziellen Nutzen gegen die bekannten Kosten abwägen und eine fundierte Entscheidung darüber treffen, ob dieser Nutzen diese Kosten wert ist.

• 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 stellen Ihnen zwei Beispielszenarien für verschiedene Anwendungsfälle vor, die jeweils ein anderes Kostenprofil aufweisen.

• Betriebliche Komplexität: Jedes Mal, wenn Sie Ihrer Lösung zusätzliche Komponenten hinzufügen, erhöht sich der 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 prüfen, ob Ihr alternativer Datenverkehrspfad auch eine gleichwertige Funktion bietet, und wenn nicht, müssen Sie entscheiden, wie Sie mit dem unterschiedlichen Verhalten der beiden Datenverkehrspfade umgehen. In realen Anwendungen können diese Komplexitäten hohe Kosten und 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. Bei den meisten Anwendungen stellt dies kein großes Problem dar, aber Sie sollten prüfen, ob die Leistung Ihrer Anwendung durch die Einführung zusätzlicher Ebenen in Ihrem Eingangspfad beeinträchtigt wird.

• Opportunitätskosten: Der Entwurf und die Implementierung redundanter Eingangspfade erfordert eine erhebliche technische Investition, die letztlich mit Opportunitätskosten für die Entwicklung von Funktionen und anderen Verbesserungen der Plattform verbunden ist.

Warnung

Wenn Sie beim Entwerfen und Implementieren einer komplexen Hochverfügbarkeitslösung nicht vorsichtig sind, können Sie Ihre Verfügbarkeit sogar verschlechtern. Wenn Sie die Anzahl der Komponenten in Ihrer Architektur erhöhen, erhöht sich die Anzahl der Fehlerquellen. Das bedeutet auch, dass Sie ein höheres Maß an betrieblicher Komplexität haben. Wenn Sie zusätzliche Komponenten hinzufügen, muss jede Änderung, die Sie vornehmen, sorgfältig geprüft werden, um zu verstehen, wie sie sich auf Ihre Gesamtlösung auswirkt.

Verfügbarkeit von Azure Traffic Manager

Azure Traffic Manager ist ein zuverlässiger Dienst, aber die Vereinbarung zum Servicelevel garantiert keine Verfügbarkeit von 100 %. 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.

Traffic Manager gibt zwischenspeicherbare DNS-Antworten zurück. Wenn die Gültigkeitsdauer (Time To Live, TTL) für Ihre DNS-Einträge das Zwischenspeichern zulässt, sind kurze Ausfälle von Traffic Manager möglicherweise kein Problem. Das liegt daran, dass nachgeschaltete DNS-Resolver möglicherweise eine vorherige Antwort zwischengespeichert haben. Sie sollten für längere Ausfälle planen. Sie können Ihre DNS-Server manuell neu konfigurieren, um Benutzer an Azure Front Door weiterzuleiten, wenn Traffic Manager nicht verfügbar ist.

Konsistenz des Datenverkehrsroutings

Es ist wichtig, die Funktionen und Features von Azure Front Door zu verstehen, die Sie verwenden und auf die Sie sich verlassen. Wenn Sie den alternativen Dienst wählen, entscheiden Sie sich für die Mindestfunktionen, die Sie benötigen, und lassen Sie andere Funktionen weg, wenn sich Ihre Lösung in einem beeinträchtigten Modus befindet.

Bei der Planung eines alternativen Datenverkehrspfads sollten Sie einige wichtige Fragen berücksichtigen:

• Verwenden Sie die Zwischenspeicherungsfeatures 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-Regelmoduls, um benutzerdefinierte Routinglogik auszuführen oder Anforderungen neu zu schreiben?
• Verwenden Sie die Web Application Firewall (WAF) von Azure Front Door, um Ihre Anwendungen zu schützen?
• Beschränken Sie den Datenverkehr basierend auf der IP-Adresse oder dem geografischen Standort?
• Wer stellt Ihre TLS-Zertifikate aus und verwaltet diese?
• Wie beschränken Sie den Zugriff auf Ihre Ursprungsanwendungsserver, um sicherzustellen, dass er über Azure Front Door erfolgt? Verwenden Sie Private Link oder verlassen Sie sich auf öffentliche IP-Adressen mit Diensttags und Bezeichnerheadern?
• Akzeptieren Ihre Anwendungsserver Datenverkehr von anderen Quellen als Azure Front Door? Wenn ja, welche Protokolle akzeptieren sie?
• Verwenden Ihre Clients die HTTP/2-Unterstützung von Azure Front Door?

Web Application Firewall (WAF)

Wenn Sie die WAF von Azure Front Door zum Schutz Ihrer Anwendung verwenden, überlegen Sie, was geschieht, wenn der Datenverkehr nicht über Azure Front Door läuft.

Wenn Ihr alternativer Pfad auch eine WAF enthält, stellen Sie sich die folgenden Fragen:

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

Warnung

Sie können sich dafür entscheiden, keine WAF für Ihren alternativen Eingangspfad zu verwenden. Dieser Ansatz kann in Betracht gezogen werden, um das Ziel der Zuverlässigkeit der Anwendung zu unterstützen. Dies ist jedoch keine bewährte Methode und wird nicht empfohlen.

Denken Sie an den Kompromiss, den Sie eingehen, wenn Sie Datenverkehr aus dem Internet ungeprüft akzeptieren. Wenn ein Angreifer einen ungeschützten sekundären Datenverkehrspfad zu Ihrer Anwendung entdeckt, sendet er möglicherweise schädlichen Datenverkehr über Ihren sekundären Pfad, auch wenn der primäre Pfad eine WAF enthält.

Es ist am besten, alle Pfade zu Ihren Anwendungsservern zu schützen.

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.

Es empfiehlt sich außerdem, einen hochwertigen und resilienten DNS-Dienst für Ihren Domänennamen zu verwenden, z. B. Azure DNS. Wenn die DNS-Server Ihres Domänennamens nicht verfügbar sind, können Benutzer Ihren Dienst nicht erreichen.

Es wird empfohlen, mehrere DNS-Resolver zu 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, der auch als CNAME-Verkettung bezeichnet wird. 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 Glieder zu einer CNAME-Kette kann die Leistung der DNS-Namensauflösung beeinträchtigen. DNS-Antworten werden jedoch in der Regel zwischengespeichert, was die Auswirkungen auf die Leistung verringert.

TLS-Zertifikate

Für eine unternehmenskritische Anwendung wird empfohlen, dass Sie Ihre eigenen TLS-Zertifikate anstelle der von Azure Front Door bereitgestellten verwalteten Zertifikate bereitstellen und verwenden. So reduzieren Sie die Anzahl der potenziellen Probleme mit dieser komplexen Architektur.

Im Anschluss sind einige Vorteile aufgeführt:

• 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 korrekt. 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 Problemen mit TLS-Zertifikaten.

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

• Wenn jeder Dienst seine eigenen verwalteten TLS-Zertifikate unabhängig erhält, können Probleme auftreten. So erwarten Benutzer möglicherweise nicht, dass verschiedene TLS-Zertifikate von verschiedenen Zertifizierungsstellen ausgestellt werden oder unterschiedliche Ablaufdaten oder Fingerabdrücke haben.

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

Ursprungssicherheit

Wenn Sie Ihren Ursprung so konfigurieren, dass nur Datenverkehr über Azure Front Door akzeptiert wird, erhalten Sie Schutz vor DDoS-Angriffen der Ebene 3 und Ebene 4. Da Azure Front Door nur auf gültigen HTTP-Datenverkehr reagiert, trägt dies auch dazu bei, die Anfälligkeit für viele protokollbasierte Bedrohungen zu verringern. Wenn Sie Ihre Architektur ändern, um alternative Eingangspfade zuzulassen, müssen Sie prüfen, ob Sie die Anfälligkeit Ihres Ursprungs für Bedrohungen versehentlich erhöht haben.

Wenn Sie Private Link verwenden, um eine Verbindung von Azure Front Door zu Ihrem Ursprungsserver herzustellen, wie fließt dann 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.

Überprüfen Sie beim Planen der Ursprungssicherheit, ob der alternative Datenverkehrspfad auf der Bereitstellung dedizierter öffentlicher IP-Adressen basiert. Hierfür ist möglicherweise ein manuell ausgelöster Prozess erforderlich, um den Sicherungspfad online zu schalten.

Wenn dedizierte öffentliche IP-Adressen vorhanden sind, sollten Sie überlegen, ob Sie Azure DDoS Protection implementieren sollten, um das Risiko von Denial-of-Service-Angriffen auf Ihre Ursprünge zu verringern. Überlegen Sie auch, ob Sie Azure Firewall oder eine andere Firewall implementieren müssen, die Sie vor einer Vielzahl von Netzwerkbedrohungen schützen kann. Möglicherweise benötigen Sie auch weitere Strategien zur Angriffserkennung. Diese Kontrollen können wichtige Elemente in einer komplexeren Architektur mit mehreren Pfaden sein.

Integritätsmodellierung

Unternehmenskritische Entwurfsmethodik erfordert ein Systemintegritätsmodell, mit dem Sie den Zustand der Lösung und ihrer Komponenten insgesamt beobachten können. 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.

Beziehen Sie diese Fragen in den Entwurf Ihres Integritätsmodells ein:

• Wie überwachen die verschiedenen Komponenten Ihrer Lösung die Integrität von Downstreamkomponenten?
• Wann sollten Downstreamkomponenten von der Integritätsüberwachung als fehlerhaft betrachtet werden?
• Wie lange dauert es, bis ein Ausfall erkannt wird?
• Wie lange dauert es, bis Datenverkehr über einen alternativen Pfad geleitet wird, nachdem ein Ausfall erkannt wurde?

Es gibt mehrere globale Lastenausgleichslösungen, mit denen Sie die Integrität von Azure Front Door überwachen und bei einem Ausfall ein automatisches Failover auf eine Sicherungsplattform auslösen können. Azure Traffic Manager ist in den meisten Fällen geeignet. Mit Traffic Manager konfigurieren Sie die Endpunktüberwachung, um Downstreamdienste zu überwachen, indem Sie angeben, welche URL wie häufig überprüft werden soll und wann der Downstreamdienst basierend auf Testantworten fehlerhaft ist. Im Allgemeinen gilt: Je kürzer das Intervall zwischen den Überprüfungen, desto weniger Zeit benötigt Traffic Manager, um den Datenverkehr über einen alternativen Pfad zu Ihrem Ursprungsserver zu leiten.

Wenn Front Door nicht verfügbar ist, beeinflussen mehrere Faktoren die Zeitspanne, in der sich der Ausfall auf Ihren Datenverkehr auswirkt, darunter:

• die Gültigkeitsdauer (TTL, Time To Live) Ihrer DNS-Einträge
• wie häufig Traffic Manager seine Integritätsprü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 feststellen, welche dieser Faktoren in Ihrem Einflussbereich liegen und ob Upstreamdienste, auf die Sie keinen Einfluss haben, die Benutzerfreundlichkeit beeinträchtigen könnten. Selbst wenn Sie beispielsweise eine niedrige Gültigkeitsdauer für Ihre DNS-Einträge verwenden, kann es vorkommen, dass die DNS-Caches von Upstreamdiensten veraltete Antworten länger ausgeben, als sie sollten. Dieses Verhalten kann die Auswirkungen eines Ausfalls verschlimmern oder den Eindruck erwecken, dass Ihre Anwendung nicht verfügbar ist, selbst wenn Traffic Manager bereits dazu übergegangen ist, Anforderungen an den alternativen Datenverkehrspfad zu senden.

Tipp

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

Weitere Informationen finden Sie unter: Unternehmenskritischer Entwurfsbereich: Integritätsmodellierung.

Bereitstellung ohne Ausfallzeit

Wenn Sie den Betrieb einer Lösung mit redundantem Eingangspfad planen, sollten Sie auch planen, wie Sie Ihre Dienste bereitstellen oder konfigurieren, wenn diese beeinträchtigt sind. Bei den meisten Azure-Diensten beziehen sich die SLAs auf die Betriebszeit des Dienstes selbst und nicht auf Verwaltungsvorgänge oder Bereitstellungen. Überlegen Sie, ob Ihre Bereitstellungs- und Konfigurationsprozesse für den Fall von Dienstausfällen resilient gemacht werden müssen.

Sie sollten auch die Anzahl der unabhängigen Steuerungsebenen berücksichtigen, mit denen Sie zum Verwalten Ihrer Lösung interagieren müssen. Wenn Sie Azure-Dienste verwenden, bietet Azure Resource Manager eine einheitliche und konsistente Steuerungsebene. Wenn Sie jedoch einen Drittanbieterdienst zum Weiterleiten von Datenverkehr verwenden, müssen Sie möglicherweise eine separate Steuerungsebene zum Konfigurieren des Diensts verwenden, was zu einer weiteren betrieblichen Komplexität führt.

Warnung

Die Verwendung mehrerer Steuerungsebenen erhöht die Komplexität und das Risiko Ihrer Lösung. Jeder Unterschied erhöht die Wahrscheinlichkeit, dass jemand versehentlich eine Konfigurationseinstellung übersieht oder unterschiedliche Konfigurationen auf redundante Komponenten anwendet. Stellen Sie sicher, dass Ihre Betriebsverfahren dieses Risiko mindern.

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

Fortlaufende Validierung

Bei einer unternehmenskritischen Lösung müssen Ihre Testverfahren sicherstellen, dass Ihre Lösung Ihre Anforderungen erfüllt, unabhängig von dem Pfad, den Ihr Anwendungsverkehr durchläuft. Betrachten Sie jeden Teil der Lösung und wie Sie ihn für jede Art von Ausfall testen.

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

• Können Sie sicherstellen, dass Datenverkehr korrekt ü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?

Weitere Informationen finden Sie unter: Unternehmenskritischer Entwurfsbereich: Fortlaufende Validierung.

Häufige Szenarios

Im Folgenden finden Sie häufige Szenarien, in denen dieser Entwurf verwendet werden kann:

• Bereitstellung globaler Inhalte bezieht sich in der Regel auf die Bereitstellung statischer Inhalte, Medien und umfangreiche eCommerce-Anwendungen. In diesem Szenario ist das Zwischenspeichern ein wichtiger Bestandteil der Lösungsarchitektur, und Fehler beim Zwischenspeichern können zu einer erheblich verminderten Leistung oder Zuverlässigkeit führen.

• Globaler HTTP-Eingang bezieht sich in der Regel auf unternehmenskritische dynamische Anwendungen und APIs. In diesem Szenario besteht die Hauptanforderung darin, Datenverkehr zuverlässig und effizient zum Ursprungsserver zu leiten. Häufig ist eine WAF eine wichtige Sicherheitskontrolle, die 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, erhöht sich die Anzahl der Fehlerquellen. Das bedeutet auch, dass Sie ein höheres Maß an betrieblicher Komplexität haben. Wenn Sie zusätzliche Komponenten hinzufügen, muss jede Änderung, die Sie vornehmen, sorgfältig geprüft werden, um zu verstehen, wie sie sich auf Ihre Gesamtlösung auswirkt.

Nächste Schritte

Sehen Sie sich die Szenarien für globalen HTTP-Eingang und Bereitstellung globaler Inhalte an, um zu verstehen, ob sie auf Ihre Lösung zutreffen.