Alles redundant machen

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 eine Fehlfunktion aufweisen und gleichzeitig aus dem Pool entfernt werden
• identischen Zustand oder keinen Zustand aufweisen
• keine laufenden Arbeiten haben, die infolge der Fehlfunktion dauerhaft verloren gehen
• sind in Funktionen identisch
• keine Abhängigkeiten voneinander haben
• regelt 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 geschäftliche 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. Stellen Sie sicher, dass Sie verstehen, wie Verfügbarkeitszonen und Regionen Resilienz und unterschiedliche Sätze von Architekturkonflikten bieten.

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 geschäftskritische Workload verfügen und das Risiko eines regionalen Ausfalls minimieren müssen, sollten Sie eine Multi-Region-Bereitstellung 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".

Platzieren Sie virtuelle Computer hinter einem Lastenausgleichsmodul. 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 von 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. Georeplikation für Azure SQL-Datenbank und Azure Cosmos DB erstellt sekundäre lesbare Replikate Ihrer Daten in einem oder mehreren sekundären Regionen. 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.

Wenn Sie eine IaaS-Datenbanklösung verwenden, wählen Sie eine Lösung aus, die Replikation und Failover unterstützt, z. B. SQL Server AlwaysOn-Verfügbarkeitsgruppen.

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 aufskaliert 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 Failover-Routingmechanismus verwenden, sollten Sie die folgenden Empfehlungen beachten.

Front- und Backend-Failover synchronisieren. 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 automatisches Failover und manuelles Failback. 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. Siehe das Health Endpoint Monitoring-Muster.

Schließen Sie Redundanz für Ihre Routinglösung ein. Erwägen Sie das Entwerfen einer globalen Routingredundanzlösung für unternehmenskritische Webanwendungen.