Herstellen von Redundanz für alle Anwendungskomponenten

Schaffen von Redundanz in Ihrer Anwendung, um Ausfälle einzelner Komponenten zu verhindern

In einer robusten Anwendung werden Ausfälle umgangen. Identifizieren Sie die kritischen Pfade in Ihrer Anwendung. Ist die Redundanz an jedem Punkt des Pfads gewährleistet? Wird für die Anwendung ein Failover durchgeführt, wenn ein Subsystem ausfällt?

Empfehlungen

Berücksichtigen Sie die geschäftlichen Anforderungen. Der Umfang der Redundanz, die in ein System integriert ist, kann sich sowohl auf die Kosten als auch auf die Komplexität auswirken. Ihre Architektur sollte sich an Ihren geschäftlichen Anforderungen orientieren, wie z. B. dem Recovery Time Objective (RTO) und dem Recovery Point Objective (RPO). Sie sollten außerdem Ihre Leistungsanforderungen sowie die Fähigkeit Ihres Teams berücksichtigen, komplexe Ressourcensätze zu verwalten.

Ziehen Sie Architekturen mit mehreren Zonen und Regionen in Betracht. Informieren Sie sich darüber, inwiefern Verfügbarkeitszonen und Regionen für Ausfallsicherheit sorgen und welche architektonischen Zielkonflikte bestehen.

Azure-Verfügbarkeitszonen sind isolierte Gruppen von Rechenzentren innerhalb einer Region. Durch den Einsatz von Verfügbarkeitszonen können Sie Ausfälle eines einzelnen Rechenzentrums oder einer ganzen Verfügbarkeitszone abfedern. Mithilfe von Verfügbarkeitszonen können Sie Kompromisse zwischen Kosten, Risikominderung, Leistung und Wiederherstellbarkeit eingehen. Wenn Sie beispielsweise zonenredundante Dienste in Ihrer Architektur verwenden, bietet Azure automatische Datenreplikation und Failover zwischen geografisch getrennten Instanzen, wodurch viele unterschiedliche Arten von Risiken entschärft werden.

Wenn Sie über eine unternehmenskritische Workload verfügen und das Risiko eines regionalen Ausfalls minimieren müssen, sollten Sie eine Bereitstellung mit mehreren Regionen in Betracht ziehen. Bereitstellungen mit mehreren Regionen schützen Sie zwar vor regionalen Notfällen, haben aber ihren Preis. Eine Bereitstellung mit mehreren Regionen ist teurer als eine Bereitstellung mit nur einer Region und komplizierter zu verwalten. Sie benötigen operative Verfahren zur Handhabung der Failover- und Failbackprozesse. Je nach Ihren RPO-Anforderungen müssen Sie möglicherweise eine etwas geringere Leistung in Kauf nehmen, um eine regionsübergreifende Datenreplikation zu ermöglichen. Die zusätzlichen Kosten und die Komplexität könnten für einige Geschäftsszenarien gerechtfertigt sein.

Tipp

Für viele Workloads bietet eine zonenredundante Architektur das beste Gleichgewicht zwischen Vor- und Nachteilen. Ziehen Sie eine Architektur mit mehreren Regionen in Betracht, wenn Ihre Geschäftsanforderungen die Minimierung des unwahrscheinlichen Risikos eines flächendeckenden Ausfalls verlangen und Sie bereit sind, die mit einem solchen Ansatz verbundenen Kompromisse zu akzeptieren.

Weitere Informationen zum Entwerfen Ihrer Lösung für die Verwendung von Verfügbarkeitszonen und Regionen finden Sie unter Empfehlungen für die Verwendung von Verfügbarkeitszonen und Regionen.

Ordnen Sie VMs hinter einem Lastenausgleichsmodul an. Verwenden Sie für unternehmenskritische Workloads keine einzelnen VMs. Ordnen Sie stattdessen mehrere VMs hinter einem Lastenausgleichsmodul an. Wenn eine VM nicht mehr verfügbar ist, verteilt der Lastenausgleich den Datenverkehr auf die restlichen intakten VMs. Informationen zur Bereitstellung dieser Konfiguration finden Sie im Artikel zum Thema [Mehrere VMs zur Steigerung von Skalierbarkeit und Verfügbarkeit][Multi-VM-Blaupause].

Replizieren Sie Datenbanken. Azure SQL-Datenbank und Azure Cosmos DB replizieren die Daten innerhalb einer Region automatisch und können so konfiguriert werden, dass sie über Verfügbarkeitszonen hinweg repliziert werden, um die Ausfallsicherheit zu erhöhen. Sie können außerdem festlegen, ob Sie die regionsübergreifende Georeplikation aktivieren möchten. Bei der Georeplikation für Azure SQL-Datenbank und Azure Cosmos DB werden sekundäre lesbare Replikate Ihrer Daten in einer oder mehreren Regionen erstellt. Wenn es in der primären Region zu einem Ausfall kommt, kann die Datenbank für Schreibvorgänge ein Failover auf die sekundäre Region durchführen. Je nach Replikationskonfiguration kann es durch nicht replizierte Transaktionen zu einem gewissen Datenverlust kommen.

Achten Sie bei Verwendung einer IaaS-Datenbanklösung darauf, dass sie Replikation und das Failover unterstützt, z. B. Always On-Verfügbarkeitsgruppen (SQL Server).

Nutzen Sie die Partitionierung, um die Verfügbarkeit sicherzustellen. Die Datenbankpartitionierung wird häufig verwendet, um die Skalierbarkeit zu verbessern, aber auch die Verfügbarkeit kann damit verbessert werden. Wenn ein Shard ausfällt, sind die anderen Shards weiterhin erreichbar. Ein Ausfall in einem Shard führt nur zu einer Störung einer Teilmenge der gesamten Transaktionen.

Lösungen mit mehreren Regionen

Im folgenden Diagramm ist eine in mehreren Regionen angeordnete Anwendung dargestellt, für die Azure Traffic Manager zur Durchführung von Failovern verwendet wird.

Wenn Sie Traffic Manager in einer Lösung mit mehreren Regionen verwenden, beachten Sie die folgenden Empfehlungen:

Synchronisieren Sie Front-End- und Back-End-Failover. Nutzen Sie Traffic Manager für das Failover des Front-Ends. Wenn das Front-End in einer Region nicht mehr erreichbar ist, leitet Traffic Manager neue Anforderungen an die sekundäre Region weiter. Abhängig von Ihren Back-End-Komponenten und Ihrer Datenbanklösung müssen Sie möglicherweise ein Failover Ihrer Back-End-Dienste und Datenbanken koordinieren.

Verwenden Sie automatische Failover und manuelle Failbacks. Nutzen Sie Traffic Manager für automatische Failover, aber nicht für automatische Failbacks. Beim automatischen Failback besteht das Risiko, dass Sie zur primären Region wechseln, bevor die Region vollständig fehlerfrei ist. Überprüfen Sie vor einem manuellen Failback stattdessen, ob alle Subsysteme der Anwendung fehlerfrei sind. Je nach Datenbank müssen Sie vor einem Failback unter Umständen auch die Datenkonsistenz prüfen.

Um dies zu erreichen, deaktivieren Sie nach dem Failover den primären Endpunkt von Traffic Manager. Beachten Sie, dass, wenn das Überwachungsintervall der Tests kurz und die tolerierte Anzahl von Ausfällen gering ist, sowohl Failover als auch Failback in kurzer Zeit erfolgen. In einigen Fällen wird die Deaktivierung nicht rechtzeitig abgeschlossen. Um ein unbestätigtes Failback zu vermeiden, sollten Sie auch die Implementierung eines Integritätsendpunkts in Erwägung ziehen, der überprüfen kann, ob alle Subsysteme fehlerfrei sind. Weitere Informationen finden Sie unter Muster für Überwachung der Integrität von Endpunkten.

Stellen Sie für Traffic Manager die Redundanz sicher. Traffic Manager ist ein möglicher Fehlerpunkt. In der Vereinbarung zum Servicelevel (SLA) für Traffic Manager erfahren Sie, ob Ihre geschäftlichen Anforderungen für Hochverfügbarkeit mit Traffic Manager allein erfüllt werden. Wenn dies nicht der Fall ist, erwägen Sie als Failback eine andere Verwaltungslösung für den Datenverkehr. Wenn der Azure Traffic Manager-Dienst fehlerhaft ist, ändern Sie die CNAME-Einträge im DNS so, dass diese auf die andere Verwaltungslösung für den Datenverkehr verweisen.