Verwenden der Spiegelung in einem Beispielszenario für die Notfallwiederherstellung
Dieses End-to-End-Disaster-Recovery-Szenario zeigt, wie die Spiegelung verwendet werden kann, um die Verfügbarkeit zu erhöhen und die Funktionsfähigkeit von Anwendungen aufrechtzuerhalten, falls ein schwerwiegender Vorfall eine vollständige IBM Cloud-Region betrifft.
Zwei Cluster wurden in verschiedenen Regionen bereitgestellt und für die Spiegelung konfiguriert (gemäß den Informationen in Aktivieren der Spiegelung), indem A und B als Cluster-Aliase
verwendet wurden.Ein Producer veröffentlicht Datensätze in einem Topic mit der Bezeichnung accounting.invoices und ein Consumer liest die Nachrichten aus diesem Topic in Cluster A.
Failover von Producern durchführen
Führen Sie zum Failover die folgenden Schritte aus:
- Stoppen Sie die Producer, die auf Cluster A verweisen.
- Wenn Cluster A und die Verbindung von A zu Cluster B noch funktionsfähig sind, stellen Sie sicher, dass so viele Daten wie möglich gespiegelt werden, indem Sie überprüfen, ob die Verzögerung bei diesen Themen auf Cluster B gleich Null ist.
- Starten Sie die Produzenten neu, damit sie auf die Endpunkte von Cluster B verweisen.
- Inaktivieren Sie jede Spiegelung, die noch für Themen von Cluster A zu Cluster B aktiviert ist. Dies kann mithilfe von Benutzersteuerelementeerfolgen.
Der Producer wurde jetzt auf Cluster B verlegt und sendet Nachrichten an ein neues lokales Topic mit demselben Namen wie der ursprüngliche Topic.
Failover von Consumern durchführen
Führen Sie zum Failover die folgenden Schritte aus:
- Wenn Cluster A und die Verbindung von A zu Cluster B weiterhin betriebsbereit sind, ermöglichen Sie den Konsumenten, alle Nachrichtendaten in den Themen in Cluster A zu lesen und ihre Offsets am Ende des Themas festzuschreiben.
- Stoppen Sie die Verbraucher, die auf Cluster A verweisen.
- Starten Sie die Verbraucher neu, damit sie auf die Endpunkte von Cluster B zeigen.
Der Verbraucher ist nun in der Lage, die bestehenden Nachrichten aus dem accounting.invoices.A Thema von Cluster B weiter zu konsumieren, während neue Nachrichten von accounting.invoices kommen.
Wenn die Anwendung eine strenge Reihenfolge erfordert, müssen entfernte Themen zuerst vollständig konsumiert werden, bevor mit dem Konsumieren von lokalen Themen begonnen wird. Auf diese Weise werden Nachrichten in der Reihenfolge verarbeitet, in der sie generiert wurden.
Spiegelungsumgebung zurücksetzen
Der Eigner der Event Streams-Serviceinstanz entscheidet, was geschieht, wenn Cluster A wiederhergestellt wird.
Falls Cluster A nicht wiederherstellbar ist, muss der Event Streams-Serviceinstanzeigner die Spiegelung zwischen Cluster B und einer neu bereitgestellten Instanz einrichten und aktivieren. Gehen Sie wie folgt vor, um die Spiegelung für eine neue Instanz zu aktivieren:
- Übernehmen Sie die Erzeuger und Verbraucher wie zuvor beschrieben von A nach B.
- Inaktivieren Sie die aktuelle Spiegelung von Cluster A auf Cluster B. Weitere Informationen finden Sie unter Spiegelung inaktivieren.
- Aktivieren Sie nach der Inaktivierung der Spiegelung die Spiegelung zwischen Cluster B (jetzt Quelle) und dem neu bereitgestellten Cluster (Ziel). Weitere Informationen finden Sie unter Spiegelung aktivieren.
Wenn sich Cluster A erholt hat, kehrt ein Benutzer normalerweise zu Cluster A zurück. Führen Sie die folgenden Schritte aus, um primäre Operationen an Cluster A zurückzugeben.
Vor dem Failback muss die Spiegelung in der Gegenrichtung aktiviert werden:
- Stellen Sie sicher, dass Cluster A voll funktionsfähig ist.
- Inaktivieren Sie die aktuelle Spiegelung von Cluster A auf Cluster B. Weitere Informationen finden Sie unter Spiegelung inaktivieren.
- Nachdem die Spiegelung inaktiviert wurde, aktivieren Sie die Spiegelung zwischen Cluster B (jetzt Quelle) und Cluster A (jetzt Ziel). Weitere Informationen finden Sie unter Spiegelung aktivieren.
- Der Quellencluster A wird nun zum Zielcluster.
- Der Zielcluster B wird zum neuen Quellencluster.
- Aktivieren Sie alle Themen, die von Cluster B auf Cluster A gespiegelt werden. Verwenden Sie dazu die Benutzersteuerelemente.
Stellen Sie als Nächstes sicher, dass Daten in Cluster A repliziert werden, indem Sie die Themen von Cluster B in Cluster A untersuchen. Diese Themen haben das Suffix des neuen Quellclusters, B.
Spiegeln Sie das ursprüngliche Zielthema nicht auf Cluster B zurück, da dies zu einem unerwünschten zyklischen Effekt führen würde. Wie im Diagramm dargestellt, spiegeln wir accounting.invoices von Cluster B auf Cluster A, nicht accounting.invoices.A.
Failback
Die Entscheidung, einen Failback durchzuführen, obliegt wiederum dem Event Streams-Instanzeigner. Der Serviceinstanzeigner muss den Failback der Anwendung, einschließlich Rekonfiguration, erneuter Bereitstellung und Neustart, koordinieren, falls dies erforderlich ist.
Im Gegensatz zum Failover-Fall gab es in diesem Fall keine Katastrophe in Cluster B. Daher ist Failback eine kontrollierte Operation und kann mit minimalem Datenverlust oder einer erneuten Verarbeitung von Daten erreicht werden.
Zum Schluss schalten Sie die Spiegelung wieder auf die ursprüngliche Konfiguration zurück, d. h. Cluster A ist wieder die Quelle und Cluster B ist wieder das Ziel.
- Stellen Sie sicher, dass Cluster A und Cluster B vollständig betriebsbereit sind.
- Inaktivieren Sie die aktuelle Spiegelung von Cluster B auf Cluster A. Weitere Informationen finden Sie unter Spiegelung inaktivieren.
- Nachdem die Spiegelung inaktiviert wurde, aktivieren Sie die Spiegelung zwischen Cluster A (jetzt Quelle) und Cluster B (jetzt Ziel). Weitere Informationen finden Sie unter Spiegelung aktivieren.