Failover auf eine Replikation

Bei einem Failover werden die Replikationsrollen vertauscht. Die Replik wird zur Lese-/Schreibquelle, während die ursprüngliche Quelle schreibgeschützt bleibt, wodurch die Datenverfügbarkeit auch bei Ausfällen gewährleistet bleibt.

Konzepte für das Failover auf eine Replikation

Wenn Sie eine Replik einer Dateifreigabe erstellen, ruft die Replik die Daten gemäß einem Replikationszeitplan aus der Quelldateifreigabe ab. Die Daten in der Replikatdateifreigabe sind schreibgeschützt. Durch das Failover wird die Replikationsbeziehung umgekehrt. Die schreibgeschützte Replikatdateifreigabe wird zur Quellendateifreigabe mit Schreib-/Lesezugriff und die ursprüngliche Freigabe wird schreibgeschützt. Sie können jetzt die aktive Dateifreigabe anhängen und als reguläre Dateifreigabe verwalten.

Wenn Sie einen Failover einleiten, können Sie auswählen, was geschieht, wenn die Failover-Operation fehlschlägt oder das Zeitlimit überschreitet. Die Standard-Zeitüberschreitung beträgt 5 Minuten.

Wenn Sie die Replikationsbeziehung beibehalten möchten, greift das System auf die gemeinsam genutzte Quellenressource zurück. Auch wenn der Vorgang fehlgeschlagen ist, versucht das System, die Daten zum nächsten geplanten Zeitpunkt erneut zu replizieren. Diese Option kann verwendet werden, wenn der primäre Standort für die routinemäßige Wartung geplant ist. Sie können auf die ursprüngliche Freigabe zurückgreifen, wenn die Wartung abgeschlossen ist und die Site wieder stabil ist. Die Replikation kann fortgesetzt werden.
Wenn Sie die Replikationsbeziehung entfernen, teilt das System die beiden Dateifreigaben auf, und sie werden zu unabhängigen Dateifreigaben mit Schreib-/Lesezugriff. Diese Option kann für die Funktionsübernahme in einer Disaster-Recovery-Situation verwendet werden, wenn es wichtiger ist, Ihre Anwendung so schnell wie möglich zu starten. So können Sie den normalen Betrieb auf der Replikatsite fortsetzen, während die Zukunft der ursprünglichen Site unsicher ist.

Ein Failover-Vorgang oder eine Replik-Aufteilung kann nicht stattfinden, wenn gerade ein anderer Vorgang an der Quell- oder Replik-Dateifreigabe durchgeführt wird (beispielsweise wenn die Dateifreigabe vergrößert wird). Der Split- oder Failover-Vorgang bleibt so lange hängen, bis der andere Vorgang abgeschlossen ist.

Der Failoverstatus zeigt failover_pending an, während die Operation ausgeführt wird oder während der Service auf den Abschluss einer anderen Operation wartet.

Failover für routinemäßige Wartung

Nutzen Sie ein Failover bei routinemäßigen Wartungsarbeiten am Primärstandort oder wenn an diesem Standort Probleme auftreten. Der Prozess funktioniert wie folgt.

Die Quellendateifreigabe in Zone A weist alle Lese-und Schreiboperationen zurück. Anschließend versucht das System, eine endgültige Kopie der gemeinsam genutzten Daten in die Replikatfreigabe in Zone B zu extrahieren.
Die Daten werden in die Replikatdateifreigabe kopiert, die Schreib-/Lesezugriff erhält und als neue Quellensite betrachtet wird. (D. h. die Replikationsbeziehung wird umgekehrt.)
Der Service versucht, Daten wie geplant von der aktiven Quelle in Zone B auf die ursprüngliche Freigabe in Zone A zu replizieren. Wenn die Datenübertragung fehlschlägt, wiederholt das System den Versuch zur nächsten geplanten Replikationszeit.
Sie können auf die ursprüngliche Freigabe zurückgreifen, wenn die Wartung abgeschlossen ist und die Site wieder stabil ist. Sie können die Replikatfreigabe auch als Quellenfreigabe beibehalten.

Failover in einer Disaster-Recovery-Situation

Failover ist auch eine Option für die Wiederherstellung nach einem Katastrophenfall. Wenn bestätigt wird, dass der ursprüngliche Standort nicht verfügbar ist, und Sie Ihre Anwendung so schnell wie möglich auf dem Replikationsstandort starten müssen, sollten Sie die Replikationsbeziehung entfernen. Das Entfernen der Replikationsbeziehung ist eine Option für die Fallback-Richtlinie, wenn Sie das Failover initiieren. Die Funktionsübernahme für die Disaster-Recovery funktioniert wie folgt:

Die Dateifreigabe am Quellenstandort verweigert alle Lese-und Schreiboperationen und das System versucht, eine endgültige Kopie der Daten der gemeinsam genutzten Ressource in die Replikatdateifreigabe zu extrahieren.
Wenn die Data-Pull-Operation das Zeitlimit überschreitet und fehlschlägt, unterbricht der Dateiservice die Replikationsbeziehung. Die Replikatdateifreigabe wird gelesen/geschrieben und fungiert als unabhängige Dateifreigabe. Sie kann angehängt und als normale Dateifreigabe verwaltet werden.
Replikationsbeziehung kann nicht wiederhergestellt werden. Sie können jedoch ein neues Replikat auf der ursprünglichen Site einrichten, wenn und wann die Site wieder betriebsbereit ist.

Aufgrund der Art des Failovers bei der Notfallwiederherstellung kann es vorkommen, dass der aktuellste Datensatz nicht kopiert wurde. In diesem Fall müssen Sie den Status Ihrer Anwendung wahrscheinlich manuell abgleichen, wenn die Quellendateifreigabe wieder verfügbar ist. Sollte die Freigabezone der Quelldatei wieder verfügbar sein, stehen Daten aus der Replikatfreigabe zur Verfügung, um den Zeitraum vom Zeitpunkt des Vorfalls bis zum Wiederherstellungspunkt abzugleichen.

Einschränkungen

Diese Einschränkungen gelten, wenn Sie einen Failover durchführen.

Das Standardzeitlimit für einen erfolgreichen Failover sind 5 Minuten. Sie können diesen Wert ändern, wenn Sie die Optionen für Failover einleiten.
Ein Failover bleibt ausstehend, solange andere Vorgänge an der Quell-Dateifreigabe durchgeführt werden, wie beispielsweise die Erweiterung der Freigabegröße. Nachdem die Operation abgeschlossen ist, wird der Failover fortgesetzt.

Initiieren einer Ausfallsicherung in der Konsole

Navigieren Sie zur Liste aller Dateifreigaben. Klicken Sie in der Konsole IBM Cloud auf das Navigation > Infrastruktur > Storage > File Storage Shares.
Klicken Sie auf den Namen einer Replik-Dateifreigabe, um deren Detailseite zu öffnen.
Wählen Sie im Menü Aktionen die Option Failover durchführen aus. Vor dem Failover wird eine abschließende Synchronisierung der Dateien durchgeführt, um sicherzustellen, dass die Failover-Freigabe die aktuellsten Inhalte enthält. Wenn der Failover abgeschlossen ist, wird die Replikatdateifreigabe zur neuen Quellendateifreigabe. Die vorherige Quellenfreigabe wird zur neuen schreibgeschützten Replikatfreigabe.
Aktivieren Sie das Kontrollkästchen unter Zeitlimit (optional) und geben Sie einen Zeitwert an, um einen Zeitlimitwert festzulegen. Dieser Wert legt ein absolutes Zeitlimit zum Abschließen der Failover-Operation fest. Das Zeitlimit sollte sich danach richten, wie lange Ihre Dateifreigabe offline sein darf.
Für den Fall, dass die Failover-Operation nicht erfolgreich verläuft oder das Zeitlimit überschreitet, können Sie unter Failover-Richtlinie angeben, ob die Replikationsbeziehung beibehalten oder geändert werden soll:
- Replikationsbeziehung beibehalten - Es werden keine Änderungen an der Replikatdateifreigabe oder der Quellendateifreigabe vorgenommen.
- Replikationsbeziehung entfernen – Diese Aktion erstellt zwei separate Lese-/Schreib-Dateifreigaben. Da die Beziehung unterbrochen ist, wirken sich Änderungen an einer Dateifreigabe nicht auf die andere Dateifreigabe aus.
Sobald Sie die Verbindung unterbrochen haben, kann sie nicht wiederhergestellt werden.
Klicken Sie auf Failover ausführen. Es werden Nachrichten angezeigt, die angeben, dass der Failover angefordert wurde und ausgeführt wird.

Die Detailseite der Dateifreigabe wird aktualisiert, und in der Replikationsbeziehung wird die Replik-Dateifreigabe als neue Quell-Dateifreigabe angezeigt.

Failover über die Befehlszeilenschnittstelle einleiten

Bevor Sie die Befehlszeilenschnittstelle (CLI) verwenden können, müssen Sie die IBM Cloud-CLI und das VPC-CLI-Plug-in installieren. Weitere Informationen finden Sie unter CLI-Voraussetzungen.

Suchen Sie die Replikatdateifreigabe, auf die die Übernahme erfolgen soll, indem Sie alle Dateifreigaben in der Region mit dem Befehl ibmcloud is shares auflisten.

ibmcloud is shares

Listing shares in all resource groups and region us-south under account Test Account as user test.user@ibm.com...
ID                                          Name                    Lifecycle state   Zone         Profile   Size(GB)   Resource group   Replication role   Accessor binding role   Snapshot count   Snapshot size
r006-a8d6af48-0c97-4c6b-bab1-fbefdc1e1e03   my-file-share           stable            us-south-2   dp2       10         defaults         none               none                    0                0
r006-aaf4bfe9-358c-4faa-a4ec-0b955090b940   my-file-share-2         stable            us-south-2   dp2       10         defaults         none               none                    0                0
r006-a60bfa90-a893-40ad-be34-28ab51a963f9   replica-dal-2           stable            us-south-2   dp2       10         defaults         replica            none                    0                0
r006-3f21e3c3-e12d-425f-ab77-810cabfde8df   source-dal-1            stable            us-south-1   dp2       10         defaults         source             none                    0                0
r006-455b601c-8fc1-4476-8771-4708c49c8ef7   my-replica-share-dal-1  stable            us-south-1   dp2       10         defaults         replica            none                    0                0
r006-4dadac27-cd17-42df-a5fe-1388705d33e0   my-source-share-dal-2   stable            us-south-2   dp2       10         defaults         source             none                    0                0

Führen Sie den Befehl ibmcloud is share-replica-failover aus und geben Sie die Eigenschaft fallback-policy an. Für diese Eigenschaft können Sie fail oder split angeben.
- Im folgenden Beispiel wird fail für die Eigenschaft fallback-policy angegeben. Wenn der Failover-Vorgang fehlschlägt oder die Zeitüberschreitung erreicht wird, ist der Failover-Vorgang nicht erfolgreich. Die Quellenfreigabe bleibt aktiv und die Replikation wird wie geplant fortgesetzt.
```
ibmcloud is share-replica-failover r006-a60bfa90-a893-40ad-be34-28ab51a963f9 --fallback-policy fail
```
```
The file share r006-a60bfa90-a893-40ad-be34-28ab51a963f9 failover request was accepted under account Test Account as user test.user@ibm.com...
The file share failover request was accepted.
```
- Im folgenden Beispiel wird split für die Eigenschaft fallback-policy angegeben. Wenn die Failover-Operation fehlschlägt, wird die Replikatfreigabe von der Quellendateifreigabe getrennt. Wenn die Funktionsübernahme fehlschlägt, ergeben sich zwei unabhängige Dateifreigaben mit Schreib-/Lesezugriff.
```
ibmcloud is share-replica-failover my-source-share-dal-2 --fallback-policy split
```
```
The file share r006-4dadac27-cd17-42df-a5fe-1388705d33e0 failover request was accepted under account Test Account as user test.user@ibm.com...
The file share failover request was accepted.
```

Weitere Informationen zu den Befehlsoptionen finden Sie unter ibmcloud is share-replica-failover.

Failover mit der API einleiten

Erstellen Sie eine Anforderung POST /shares/{share_id}/failover und geben Sie die Eigenschaften timeout und fallback_policy an. Das Mindestzeitlimit beträgt 300 Sekunden, der maximale Wert 3.600 Sekunden. Diese Anforderung leitet einen Failover einer Quellendateifreigabe auf die Replikatfreigabe ein, die durch die Replikatdateifreigabe-ID angegeben wird.

Die Eigenschaft fallback_policy kann die folgenden Werte haben: split oder fail. Wenn „ fail “ angegeben ist und der Failover-Vorgang fehlschlägt oder die Zeitüberschreitung erreicht wird, ist der Failover-Vorgang nicht erfolgreich. Die Replikationsbeziehung bleibt unverändert.

Wenn Sie split für die Eigenschaft fallback_policy angeben, wird die Replikatfreigabe von der Quellenfreigabe getrennt, sobald eine Failover-Operation fehlschlägt. Das Ergebnis sind zwei unabhängige Datei-Freigaben mit Lese- und Schreibzugriff. Da in diesem Fall die endgültige Dateisynchronisierung nicht abgeschlossen wurde, enthält die Replik-Freigabe möglicherweise nicht alle Daten der Quell-Dateifreigabe. Verwenden Sie diese Option für die Disaster-Recovery, wenn bekannt ist, dass die Quellendateifreigabe nicht erreichbar ist.

Wenn die Eigenschaft fallback_policy nicht in der Anforderung angegeben ist, nimmt das System standardmäßig den Wert split an, wenn die Failover-Operation fehlschlägt.

In diesem Beispiel wird fail für die Eigenschaft fallback_policy angegeben. Die Eigenschaft timeout ist optional. Sie können das Standard-Timeout verwenden.

curl -X POST \
"$vpc_api_endpoint/v1/shares/$replica_id?/failover?version=2023-08-08"\
-H "Authorization: Bearer $iam_token"\
-d '{
     "fallback_policy": "fail",
      "timeout": 600
    }'

Eine erfolgreiche Antwort bedeutet, dass die Failover-Anforderung für die Dateifreigabe akzeptiert wurde.

Mithilfe der API können Sie überprüfen, ob das Replikations-Failover erfolgreich war, noch aussteht oder fehlgeschlagen ist. Führen Sie einen Aufruf GET /shares/{replica_id} aus. Prüfen Sie die Eigenschaft latest_job. Weitere Informationen finden Sie unter Replikation mit der API überprüfen.

Failover mit Terraform einleiten

Wenn ein Failover durchgeführt wird, wird der gemeinsam genutzte Replikatbereich zur Quelle und der gemeinsam genutzte Quellenbereich wird zum Replikat. Die Terraform-Konfiguration muss geändert werden, damit sie dieser Änderung entspricht. Die „ fallback_policy “ legt fest, welche Maßnahme zu ergreifen ist, wenn die Failover-Anforderung zwar akzeptiert wird, aber nicht ausgeführt werden kann oder eine Zeitüberschreitung auftritt. Akzeptierte Werte sind split oder fail. Wenn Sie split angeben und der Failover nicht erfolgreich ist, unterbricht das System die Replikationsbeziehung und die beiden Dateifreigaben werden voneinander unabhängig.

resource "ibm_is_share_replica_operations" "test" {
  share_replica = ibm_is_share.replica.id
  fallback_policy = "split"
  timeout = 500
}

Weitere Informationen zu den Argumenten und Attributen finden Sie unter ibm_is_share_replica_operations.

Nächste Schritte

Replikation verwalten