Was sind Failover und Failback?

Dieser Artikel enthält eine allgemeine Übersicht darüber, wie Sowohl Failover als auch Failback in einer Cloudumgebung ausgeführt werden. Um jedoch das Failover zu verstehen, sollten Sie zunächst Redundanz und Replikation verstehen. Weitere Informationen zu diesen Konzepten, bevor Sie mit diesem Artikel fortfahren, finden Sie unter Redundanz, Replikation und Sicherung.

Ein häufiger Grund für die Aufrechterhaltung redundanter Kopien von Anwendungen und Datenreplikaten ist das Ausführen eines „Failovers“. Mit einem Failover können Sie Datenverkehr und Anforderungen von fehlerhaften Instanzen zu fehlerfreien Instanzen umleiten. Sobald die ursprünglichen Instanzen wieder fehlerfrei sind, können Sie einen Failback ausführen, um zur ursprünglichen Konfiguration zurückzukehren.

Rollen für aktive und passive Instanzen

Im Kontext des Failovers kann eine Instanz eine einzelne Komponente, z. B. eine Datenbank, oder eine Sammlung mehrerer Komponenten sein, aus denen eine Dienstbereitstellung in einer Region besteht. Bei einer gesamten Lösung können Sie verschiedene Teile dieser Lösung auf unterschiedliche Weise und in unterschiedlichen Situationen überschlagen.

Eine Komponente oder eine Sammlung von Komponenten, die für Failover und Failback konfiguriert sind, erfordert mehrere Instanzen. Jede dieser Instanzen setzt eine bestimmte Rolle voraus:

• Primäre oder aktive Instanzen funktionieren aktiv, z. B. das Verarbeiten eingehender Anforderungen von Clients. In der Regel gibt es jeweils eine primäre Instanz.
• Sekundäre oder passive Instanzen sind inaktiv, können aber bei Bedarf zur primären Instanz wechseln. Möglicherweise gibt es mehrere sekundäre Instanzen.

Es gibt eine Reihe von Möglichkeiten zum Konfigurieren passiver Instanzen. Jede Möglichkeit umfasst Kompromisse zwischen Wiederherstellungszeit und anderen Faktoren, z. B. Kosten und betriebliche Komplexität:

• Hot Standbys, die so konzipiert sind, dass sie jederzeit den Produktionsverkehr akzeptieren können.
• Warm standbys, die so konzipiert sind, dass sie fast bereit sind, den Produktionsdatenverkehr zu akzeptieren, aber dies erfordert möglicherweise einige Konfigurationsänderungen oder Skalierungsvorgänge, die abgeschlossen werden müssen, bevor sie Datenverkehr akzeptieren können.
• Pilotlicht-Standbys, die teilweise in einer minimalen Konfiguration bereitgestellt werden und eine erhebliche Vorbereitung erfordern, bevor sie den Produktionsverkehr akzeptieren können.
• Cold Standbys, die möglicherweise gar nicht bereitgestellt werden und deren Komponenten bereitgestellt werden müssen, bevor sie Produktions-Traffic akzeptieren können.

Tipp

Einige Lösungen werden entwickelt, um einen active-active Ansatz zu verwenden, was bedeutet, dass mehrere Instanzen alle Anfragen bedienen. Für ein aktiv aktives System ist kein Failover erforderlich, da alle Instanzen Jederzeit Anforderungen aktiv verarbeiten.

Failoverbereiche

Verschiedene Situationen erfordern unterschiedliche Failoverstrategien. Um diese möglichen Strategien zu veranschaulichen, betrachten Sie eine Beispiellösung, die aus einer Anwendung besteht, die aus Daten aus einer Datenbank zugreift. Sie konfigurieren die Lösung für failover, indem Sie redundante Kopien ihres Anwendungsservers und mehrere Replikate der Datenbank erstellen. Als Nächstes konfigurieren Sie Folgendes:

• Zonenredundanz durch Platzieren von Kopien und Replikaten in verschiedenen Verfügbarkeitszonen in einer Azure-Region.
• Georedundanz durch die Verwendung eines globalen Lastenausgleichs zum Umschalten zwischen Regionen.

Hier ist ein vereinfachtes Diagramm, das die allgemeine Architektur in normalen Vorgängen veranschaulicht:

In dieser Lösung können unterschiedliche Failoverereignisse ausgelöst werden. Jede dieser Komponenten entspricht einem Failoverbereich, der die Granularität der Komponenten darstellt, die fehlschlagen:

• Ein Datenbankreplikatfailover kann auftreten, wenn das aktive Datenbankreplikat nicht verfügbar ist. Das passive Replikat wird zum aktiven Replikat heraufgestuft. In der Regel können Anwendungen ihre Anforderungen schnell an das neue aktive Replikat umleiten:

  

• Ein Verfügbarkeitszonenfailover kann auftreten, wenn eine vollständige Verfügbarkeitszone einen Ausfall erlebt. Diese Art von Ausfall erfordert, dass der gesamte Datenverkehr an den Webserver in der verbleibenden Zone weitergeleitet wird, und stellt außerdem sicher, dass das Datenbankreplikat in der Surviving-Zone zum aktiven Replikat wird, wenn es noch nicht geschehen ist:

  

• Ein Regionsfailover kann auftreten, wenn es einen katastrophalen Verlust der gesamten primären Azure-Region gibt.

  

Während jeder dieser Bereiche einen Failovertyp bereitstellt, weisen sie möglicherweise unterschiedliche Failoveranforderungen und -prozesse auf. Darüber hinaus ist Microsoft möglicherweise für einige Failoverbereiche verantwortlich, z. B. wenn Sie zonenredundante Dienste verwenden, während Sie möglicherweise für das Failover in breiteren Bereichen verantwortlich sind, z. B. ein Failover zwischen Azure-Regionen.

Failover- und Geschäftskontinuitätsplanung

Ein Teil der Geschäftskontinuitätsplanung ist das Entwerfen Ihrer Failoverstrategien, einschließlich der verschiedenen Bereiche, in denen Sie fehlschlagen können.

Im Allgemeinen sollten Ihre Geschäftskontinuitätspläne automatisierte Failoverprozeduren innerhalb oder zwischen Verfügbarkeitszonen enthalten. Diese Art von Failover ist Teil Ihrer Hochverfügbarkeitsstrategie. Wenn beispielsweise das aktive Replikat einer Datenbank fehlschlägt, kann ein automatisierter Prozess ein passives Replikat höher stufen, um das aktive Replikat zu werden. Anschließend kommunizieren die Webserver mit dem neuen aktiven Replikat. Ähnlich dazu sind viele Lösungen darauf ausgelegt, bei einem Ausfall einer Verfügbarkeitszone automatisch die Wiederherstellung mithilfe der verbleibenden Zonen zu ermöglichen.

Verschiedene Failoverprozeduren werden für Notfallszenarien verwendet, z. B. im unwahrscheinlichen Fall eines vollständigen Ausfalls einer Region. Bei einem Regionsausfall können Sie die eingehenden Webanforderungen wechseln, um die zweite Region zu verwenden, sowie ein Failover der Datenbank in ein Replikat in der sekundären Region auszulösen.

Beachten Sie, dass Das Einschließen von Failoverprozeduren in die Geschäftskontinuitätsplanung erfordert, dass Sie detailliertere Entwurfs- und Testvorgänge durchführen müssen. Weitere Informationen finden Sie unter Was sind Geschäftskontinuität, Hochverfügbarkeit und Notfallwiederherstellung?.

Geplante und ungeplante Failovers

Nicht geplante Failovers sind diejenigen, die während eines Ausfalls einer Komponente ausgeführt werden, sodass Sie den Dienst mithilfe einer anderen Instanz wiederherstellen können. Ungeplante Failover führen manchmal zu Ausfallzeiten oder Datenverlusten, je nachdem, wie eine Lösung entworfen wurde. Ungeplante Failover erfordern etwas, um den Fehler zu erkennen und eine Entscheidung darüber zu treffen, wann das Failover ausgelöst werden soll.

Im Gegensatz dazu sind geplante Failovers diejenigen, die Sie proaktiv auslösen. Sie können dies in Erwartung eines Ereignisses tun, z. B. einem virtuellen Computer, der gepatcht und neu gestartet wird. Geplante Failovers haben möglicherweise eine geringere Toleranz für Ausfallzeiten und Datenverlust, da sie Teil regulärer Wartungsprozeduren sind.

Funktionsweise des Failovers

Failover besteht in der Regel aus den folgenden Schritten, die manuell oder von einem automatisierten System ausgeführt werden können. Die spezifischen Details für jede dieser Schritte hängen vom jeweiligen System ab.

1. Erkennen eines Fehlers (nur ungeplante Failovers). Ein automatisiertes Failover erfordert, dass ein Mechanismus erkennt, wenn eine Instanz nicht verfügbar ist, was in der Regel auf einer Art von Gesundheitsprüfung basiert. Verschiedene Dienste definieren ihre Gesundheit auf unterschiedliche Weise. Beispielsweise senden einige Dienste proaktiv Taktereignisse zwischen Instanzen. Andere erfordern eine separate Komponente, um jede Instanz in regelmäßigen Intervallen zu untersuchen. Es dauert oft einige Zeit, bis Gesundheitsmonitore erkannt haben, dass eine Instanz fehlgeschlagen ist, und es ist oft wichtig, eine Schonfrist zu geben, falls die Instanz einfach ausgelastet war und nicht reagieren konnte.

2. Wählen Sie den Failover. Irgendwann wird eine Entscheidung getroffen, ein Failover durchzuführen. Die Entscheidung könnte von einem automatisierten Tool oder manuell getroffen werden. Die Risikotoleranz Ihrer Organisation kann sich darauf auswirken, wie schnell diese Entscheidung getroffen wird. Wenn Sie eine geringe Risikotoleranz haben, könnten Sie sich entscheiden, schnell auf eine Alternative umzuschalten, wenn ein Problem vorliegt. Wenn Sie eine höhere Risikotoleranz haben, könnten Sie abwarten, um zu sehen, ob das Problem gelöst werden kann, bevor Sie auf ein Backup-System umschalten.

3. Wählen Sie eine neue primäre Instanz aus. Eine der verbleibenden Instanzen sollte die neue primäre Instanz werden.

   In einigen Fällen haben Sie möglicherweise vordefiniert, welche Instanz zur neuen primären Instanz werden soll, oder Sie haben nur eine Instanz, zu der Sie wechseln können.

   In anderen Situationen gibt es einen automatisierten Prozess, mit dem das System eine neue primäre Instanz auswählt. Es gibt eine Reihe von Konsensalgorithmen , die bei der verteilten Berechnung verwendet werden, einschließlich der Wahl von Führern. Diese Algorithmen werden in den relevanten Diensten implementiert, z. B. Datenbanken. In einigen Systemen ist es wichtig, dass jede Instanz das neue primäre Replikat kennt und die Ergebnisse der Auswahl für jedes Replikat automatisch angekündigt werden.

4. Umleitungsanforderungen. Konfigurieren Sie Ihre Umgebung so, dass Anforderungen an die fehlerfreien Instanzen oder an die neue primäre Instanz weitergeleitet werden.

   Um dies zu erreichen, müssen Sie möglicherweise andere Systeme aktualisieren, damit sie wissen, wo Anforderungen gesendet werden sollen. Dies könnte das Aktualisieren eines Lastenausgleichssystems umfassen, um die nicht funktionsfähige Instanz auszuschließen. In anderen Situationen wird das Dns (Domain Name System) häufig als Methode zum Senden von Anforderungen an eine aktive Instanz eines Systems verwendet. Im Rahmen des Failoverprozesses müssen Sie in der Regel DNS-Einträge aktualisieren, damit Anforderungen an die neue primäre Instanz weitergeleitet werden. DNS verfügt über das Konzept einer Time-to-Live (TTL), die Clients anweist, wie häufig sie nach aktualisierten DNS-Einträgen suchen sollen. Wenn Ihr TTL auf einen hohen Wert festgelegt ist, kann es eine Weile dauern, bis Clients Informationen zum Failover erhalten, und sie senden möglicherweise weiterhin Anforderungen an die alte primäre Instanz.

Da Failoverprozesse Verzögerungen umfassen können, ist es wichtig, dass Sie Ihre Failoverprozeduren planen, um Ihre Anforderungen an Ausfallzeiten (Ihr Wiederherstellungspunktziel oder RTO) und Datenverlust (Ihr Wiederherstellungspunktziel oder RPO) zu erfüllen. Weitere Informationen finden Sie unter Was sind Geschäftskontinuität, hohe Verfügbarkeit und Notfallwiederherstellung?.

Failback

Failback ist der Prozess der Wiederherstellung und Umleitung von Datenverkehr zurück zur ursprünglichen primären Instanz.

In manchen Situationen ist es nicht notwendig, überhaupt eine Rückschaltung durchzuführen, da jede Instanz gleichermaßen in der Lage ist, als primäre Instanz zu fungieren. Es gibt jedoch einige Situationen, in denen es wichtig ist, einen Failback durchzuführen, z. B. wenn Sie Ihre Anwendungen aus einer bestimmten Azure-Region ausführen müssen und während eines regionalen Ausfalls vorübergehend zu einer anderen Region übergelaufen sind.

Manchmal wird Failback in der gleichen Weise wie ein Failover behandelt. Jedoch kann Failback aus mehreren Gründen auch komplexer als Failover sein.

• Datensynchronisierungsprobleme. Während und auch nach einem regulären Failover hat die vorherige primäre Instanz möglicherweise noch einige Arbeit ausgeführt oder einige Daten in einen Datenspeicher geschrieben. Ein Teil des Failbackprozesses besteht darin, die Datenkonsistenz und Integrität in Ihrer Lösung sicherzustellen, einschließlich der Verwaltung von Konflikten oder Duplizierungen zwischen den primären und sekundären Instanzen.

  Es ist üblich, dass bei Datensynchronisierungsproblemen manuelles Eingreifen erforderlich ist. Wenn Sie die widersprüchlichen Daten nicht benötigen, können Sie die Datenbank oder den anderen Zustand zurücksetzen.

• Schritte zur Korrektur. Wenn vor dem Failover korrekturschritte versucht wurden, haben sie möglicherweise die primäre Instanz in einem unbekannten Zustand verlassen.

  Wenn das Risiko besteht, dass sich die primäre Instanz in einem inkonsistenten Zustand befindet, müssen Sie die primäre Instanz möglicherweise zerstören und erneut bereitstellen, sodass sie sich in einem bekannten guten Zustand befindet, bevor Sie einen Failback ausführen.

• Zusätzliche Ausfallzeiten. Ausfallzeiten während des Failbackprozesses können aufgrund von erforderlichen Neukonfigurationen oder Vorgängen zur Wiederherstellung der Datenkonsistenz länger sein als während eines Failovers.

  Sie können dieses Problem mindern, indem Sie Failbackprozesse während eines Wartungsfensters ausführen oder Benutzer über die Änderung im Voraus beraten. Außerdem können Sie möglicherweise einige vorbereitende Vorgänge durchführen, während das System online ist, und die erforderliche Ausfallzeit minimieren.

• Risikotoleranz. Wenn das Failover aufgrund eines Ausfalls aufgetreten ist, kann die Toleranz der Organisation für Ausfallzeiten oder andere Risiken während eines Failbacks niedriger sein.

  Die Geschäftsbeteiligten sollten während des gesamten Prozesses über die Situation informiert werden und sich der Notwendigkeit eines Failbacks und der Folgen der Failback-Verfahren vollständig bewusst gemacht werden. Möglicherweise können Sie einen geeigneten Zeitpunkt aushandeln, um die Änderungen vorzunehmen.

Failover und Failback in Azure-Diensten

Obwohl es wichtig ist, zu verstehen, wie Failover im Allgemeinen funktioniert, denken Sie daran, dass jeder Azure-Dienst Failover und Failback anders angehen kann. Informationen dazu, wie bestimmte Azure-Dienste aus Zuverlässigkeitsperspektive funktionieren, finden Sie im Zuverlässigkeitsleitfaden der einzelnen Dienste.

Viele Azure-Dienste behandeln bestimmte Failovertypen automatisch. Wenn Sie beispielsweise Azure-Dienste verwenden, die so konfiguriert sind, dass sie zonenredundant sind, führt Microsoft automatisch Failover zwischen Verfügbarkeitszonen für Sie aus. Weitere Informationen finden Sie unter "Was sind Verfügbarkeitszonen?" und die Azure-Dienstzulässigkeitsleitfäden.

Wenn Sie virtuelle Computer verwenden, repliziert Azure Site Recovery virtuelle Computer und deren Datenträger zwischen Verfügbarkeitszonen oder in eine andere Azure-Region und kann Failover für Sie ausführen.

Wenn Sie Ihre eigene Lösung entwerfen, die mehrere Azure-Dienste kombiniert, werden Ihre Failoveranforderungen möglicherweise komplexer. Angenommen, Sie entwerfen eine Lösung mit einer Anwendungsebene und -datenbank und möchten eine aktive/passive Architektur mit mehreren Regionen erstellen. Während eines Ausfalls in der primären Region ist es wichtig, dass Ihre Anwendung und Datenbank beide zusammen in die sekundäre Region überschlagen. Je nach den genauen Diensten, die Sie verwenden, müssen Sie möglicherweise Ihren eigenen Failoveransatz planen, um zwischen den Bereitstellungen in den einzelnen Regionen zu wechseln. Azure bietet globales Datenverkehrsrouting und Lastenausgleich über Azure Front Door und Azure Traffic Manager, und Sie können die Technologie auswählen, die Ihre Failoveranforderungen erfüllt. Jeder Dienst unterstützt die Überwachung des Status jeder regionalen Instanz Ihrer Anwendung, und Sie können ihn so konfigurieren, dass datenverkehr automatisch an die fehlerfreie Instanz umgeleitet wird.

Nächste Schritte

• Erfahren Sie mehr über die gemeinsame Verantwortung für Zuverlässigkeit.
• Erfahren Sie mehr über Empfehlungen für das hochverwendige Multi-Region-Design im Azure Well-Architected Framework.