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?
Bei einer perfekten Implementierung könnte das Hinzufügen einheitlicher Redundanz die Verfügbarkeit Ihres Systems exponentiell erhöhen. Stellen Sie sich beispielsweise vor, Sie haben N gleichwertige, gleich ausgewogene Komponenten, die:
- kann unabhängig und gleichzeitig aus dem Pool entfernt werden
- identischen Zustand oder keinen Zustand aufweisen
- keine laufenden Arbeiten haben, die während der Fehlfunktion dauerhaft verloren gehen
- sind in Funktionen identisch
- keine Abhängigkeiten voneinander haben
- behandelt die Reduzierung der Kapazität ohne zusätzliche Fehlfunktion
Wenn jede einzelne Komponente über eine Verfügbarkeit verfügt A, kann die Gesamtsystemverfügbarkeit mithilfe der Formel 1 - (1 - A)^Nberechnet werden.
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.
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.
Testen und überprüfen Sie Ihre redundanten Komponenten. Zuverlässigkeit profitiert in vielerlei Hinsicht von der Einfachheit und dem Hinzufügen von Redundanz kann die Komplexität erhöhen. Um sicherzustellen, dass das Hinzufügen von Redundanz tatsächlich zu einer höheren Verfügbarkeit führt, sollten Sie Folgendes überprüfen:
- Kann Ihr System fehlerfreie und ungesunde redundante Komponenten zuverlässig erkennen und sicher und zügig aus dem Komponentenpool entfernen?
- Kann Ihr System zuverlässig und in den redundanten Komponenten skaliert werden?
- Können Ihre Routine-, Ad-hoc- und Notfallworkloadvorgänge die Redundanz bewältigen?
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 oder Azure Front Door in einer Lösung für mehrere Regionen als Routingmechanismus „Failover“ verwenden, sollten Sie die folgenden Empfehlungen berücksichtigen:
Synchronisieren Sie Front-End- und Back-End-Failover. Verwenden Sie Ihren Routingmechanismus, um für das Front-End ein Failover durchzuführen. Wenn das Front-End in einer Region nicht mehr erreichbar ist, leitet das Failover neue Anforderungen an die sekundäre Region weiter. Je nachdem, welche Back-End-Komponenten und Datenbanklösung Sie verwenden, müssen Sie möglicherweise das Failover für Ihre Back-End-Dienste und Ihre Datenbanken koordinieren.
Verwenden Sie automatische Failover und manuelle Failbacks. Verwenden Sie die Automatisierung für das Failover, jedoch nicht für das Failback. 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. Außerdem sollten Sie die Datenkonsistenz überprüfen, bevor Sie ein Failback durchführen.
Um dies zu erreichen, deaktivieren Sie nach dem Failover den primären Endpunkt. 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.
Schließen Sie Redundanz für Ihre Routinglösung ein. Ziehen Sie die Erstellung einer Lösung für globale Routingredundanz für geschäftskritische Webanwendungen in Erwägung.