Zuverlässigkeit in Azure Spring Apps
Dieser Artikel enthält ausführliche Informationen zur regionalen Resilienz mit Verfügbarkeitszonen und Unterstützung bei regionsübergreifender Notfallwiederherstellung und Geschäftskontinuität für Azure Spring Apps.
Unterstützung für Verfügbarkeitszonen
Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.
Weitere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Was sind Verfügbarkeitszonen?.
Azure Spring Apps unterstützt zonenbasierte Redundanz. Wenn Sie eine Azure Spring Apps-Dienstinstanz mit aktivierter Zonenredundanz erstellen, verteilt Azure Spring Apps automatisch grundlegende Ressourcen auf logische Abschnitte der zugrunde liegenden Azure-Infrastruktur. Die zugrunde liegende Computeressource verteilt VMs auf alle Verfügbarkeitszonen, um Computevorgänge sicherzustellen. Die zugrunde liegende Speicherressource repliziert Daten in Verfügbarkeitszonen, damit sie auch bei Ausfällen von Rechenzentren verfügbar bleiben. Diese Verteilung ermöglicht ein höheres Maß an Verfügbarkeit und schützt vor Hardwareausfällen oder bei geplanten Wartungsereignissen.
Voraussetzungen
Zonenredundanz ist im Basic-Plan nicht verfügbar.
Azure Spring Apps unterstützt Verfügbarkeitszonen in den folgenden Regionen:
- Australien (Osten)
- Brasilien Süd
- Kanada, Mitte
- USA, Mitte
- Asien, Osten
- East US
- USA (Ost) 2
- Frankreich, Mitte
- Deutschland, Westen-Mitte
- Nordeuropa
- Japan, Osten
- Südkorea, Mitte
- Südafrika, Norden
- USA Süd Mitte
- Asien, Südosten
- UK, Süden
- Europa, Westen
- USA, Westen 2
- USA, Westen 3
Erstellen einer Azure Spring Apps-Instanz mit aktivierten Verfügbarkeitszonen
Hinweis
Sie können Zonenredundanz nur aktivieren, wenn Sie Ihre neue Azure Spring Apps-Dienstinstanz erstellen. Sie können die Zonenredundanzeigenschaft nach der Erstellung nicht ändern.
Sie können Zonenredundanz in Azure Spring Apps mithilfe der Azure CLI oder im Azure-Portal aktivieren.
Wenn Sie die Azure CLI verwenden, um einen Dienst in Azure Spring Apps mit aktivierter Zonenredundanz zu erstellen, schließen Sie beim Erstellen des Diensts den Parameter --zone-redundant ein wie im folgenden Beispiel gezeigt:
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
Aktivieren Ihrer eigenen Ressource mit aktivierten Verfügbarkeitszonen
Sie können Ihre eigene Ressource in Azure Spring Apps aktivieren, z. B. Ihren eigenen persistenten Speicher. Sie müssen jedoch sicherstellen, dass Zonenredundanz für Ihre Ressource aktiviert wird. Weitere Informationen finden Sie unter Aktivieren Ihres eigenen beständigen Speichers in Azure Spring Apps.
Zonenausfall
Wenn eine App-Instanz fehlschlägt, da sie sich auf einem VM-Knoten in einer fehlerhaften Zone befindet, erstellt Azure Spring Apps eine neue App-Instanz für die fehlgeschlagene App auf einem anderen VM-Knoten in einer anderen Verfügbarkeitszone. Benutzer können während dieser Zeit eine kurze Unterbrechung erleben. Es ist keine Benutzeraktion erforderlich, und die betroffene Azure Spring Apps-Instanz wird vom Dienst wiederhergestellt.
Preiskalkulation
Mit dem Aktivieren der Zonenredundanz sind keine zusätzlichen Kosten verbunden. Sie müssen nur für den Standard- oder Enterprise-Dienstplan bezahlen, der zum Aktivieren der Zonenredundanz erforderlich ist.
Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität
Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.
Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan zu entwickeln.
Der Azure Spring Apps-Dienst bietet keine georedundante Notfallwiederherstellung, sorgfältige Planung kann aber zum Schutz vor Downtime beitragen.
Um Hochverfügbarkeit und Schutz vor Notfällen zu gewährleisten, stellen Sie Ihre in Azure Spring Apps gehosteten Anwendungen in mehreren Regionen bereit. Azure stellt eine Liste mit Regionspaaren zur Verfügung, sodass Sie Ihre Anwendungsbereitstellungen entsprechend planen können.
Berücksichtigen Sie die folgenden Hauptfaktoren beim Entwerfen Ihrer Architektur:
- Regionale Verfügbarkeit: Um die Netzwerkverzögerung und Übertragungszeit zu minimieren, wählen Sie eine Region, die Azure Spring Apps-Zonenredundanz unterstützt, oder einen geografischen Bereich in der Nähe Ihrer Benutzer aus.
- Azure-Regionspaare. Wählen Sie Regionspaare im ausgewählten geografischen Bereich aus, sodass koordinierte Plattformupdates und priorisierte Wiederherstellungsvorgänge bei Bedarf sichergestellt sind.
- Dienstverfügbarkeit. Legen Sie fest, ob die Regionspaare heiß/heiß, heiß/warm oder heiß/kalt sein sollen.
Weiterleiten von Datenverkehr mit Azure Traffic Manager
Azure Traffic Manager gewährleistet einen DNS-basierten Lastausgleich des Datenverkehrs und kann Netzwerkdatenverkehr auf mehrere Regionen verteilen. Verwenden Sie Azure Traffic Manager, um Kunden an die nächstgelegene Azure Spring Apps-Dienstinstanz weiterzuleiten. Optimale Leistungs- und Redundanzwerte werden erzielt, indem Sie den gesamten Anwendungsdatenverkehr über Azure Traffic Manager leiten, bevor er an die Azure Spring Apps-Dienstinstanz gesendet wird. Weitere Informationen finden Sie unter Was ist Traffic Manager?.
Wenn Sie Anwendungen in Azure Spring Apps in mehreren Regionen ausführen, kann Azure Traffic Manager den Datenverkehrsfluss zu Ihren Anwendungen in jeder Region steuern. Definieren Sie einen Azure Traffic Manager-Endpunkt für jede Dienstinstanz unter Verwendung der Instanz-IP-Adresse. Sie sollten eine Verbindung mit einem DNS-Namen in Azure Traffic Manager herstellen, der auf die Azure Spring Apps-Dienstinstanz verweist. Mit Azure Traffic Manager wird ein Lastausgleich des Datenverkehrs über die definierten Endpunkte vorgenommen. Bei einem Ausfall eines Rechenzentrums leitet Azure Traffic Manager den Datenverkehr von dieser Region an die zugehörige andere Region des Regionspaars weiter, um die Dienstkontinuität sicherzustellen.
Führen Sie die folgenden Schritte aus, um eine Azure Traffic Manager-Instanz für Azure Spring Apps-Instanzen zu erstellen:
Erstellen Sie Azure Spring Apps-Instanzen in zwei unterschiedlichen Regionen. Erstellen Sie beispielsweise Dienstinstanzen in den Regionen „USA, Osten“ und „Europa, Westen“, wie in der folgenden Tabelle dargestellt. Jede Instanz dient als primärer Endpunkt und Failoverendpunkt für den Datenverkehr.
Dienstname Standort Application service-sample-a USA, Osten gateway / auth-service / account-service service-sample-b Europa, Westen gateway / auth-service / account-service Richten Sie eine benutzerdefinierte Domäne für die Dienstinstanzen ein. Weitere Informationen finden Sie unter Tutorial: Zuordnen einer bereits vorhandenen benutzerdefinierten Domäne zu Azure Spring Apps. Nach erfolgreicher Einrichtung werden beide Dienstinstanzen an dieselbe benutzerdefinierte Domäne gebunden, etwa
bcdr-test.contoso.com.Erstellen Sie ein Traffic Manager-Profil und zwei Endpunkte. Anweisungen finden Sie unter Schnellstart: Erstellen eines Traffic Manager-Profils im Azure-Portal. Dadurch wird das folgende Traffic Manager-Profil generiert:
- Traffic Manager-DNS-Name:
http://asa-bcdr.trafficmanager.net - Endpunktprofile:
Profil Typ Ziel Priorität Benutzerdefinierte Headereinstellungen Endpunkt für das Profil A Externer Endpunkt service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comEndpunkt für das Profil B Externer Endpunkt service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Traffic Manager-DNS-Name:
Erstellen Sie einen CNAME-Eintrag in einer DNS-Zone ähnlich wie im folgenden Beispiel:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.
Die Umgebung ist jetzt eingerichtet. Wenn Sie die Beispielwerte in den verknüpften Artikeln verwendet haben, sollten Sie mithilfe von https://bcdr-test.contoso.com auf die App zugreifen können.
Verwenden von Azure Front Door und Azure Application Gateway zum Weiterleiten von Datenverkehr
Azure Front Door ist ein globaler und skalierbarer Einstiegspunkt, der es ermöglicht, über das globale Microsoft-Edge-Netzwerk schnelle, sichere und umfassend skalierbare Webanwendungen zu erstellen. Azure Front Door bietet die gleiche Multi-Georedundanz und das Routing an die nächstgelegene Region wie Azure Traffic Manager. Azure Front Door bietet auch erweiterte Features wie die TLS-Protokollbeendigung, die Verarbeitung auf Anwendungsebene und Web Application Firewall (WAF). Weitere Informationen finden Sie unter Was ist Azure Front Door?.
Das folgende Diagramm zeigt die Architektur einer Redundanz in mehreren Regionen und einer in ein virtuelles Netzwerk integrierten Azure Spring Apps-Dienstinstanz. Das Diagramm zeigt die richtige Reverseproxykonfiguration für Application Gateway und Front Door mit einer benutzerdefinierten Domäne. Diese Architektur basiert auf dem unter Verfügbarmachen von Anwendungen mit End-to-End-TLS in einem virtuellen Netzwerk beschriebenen Szenario. Dieser Ansatz kombiniert zwei in Application Gateway integrierten Azure Spring Apps-Instanzen mit Einschleusung virtueller Netzwerke in einer georedundanten Instanz.
