Ausfallübernahme von einem nicht erreichbaren Primärvolume zur Notfallwiederherstellung

Lösen Sie ein Failover auf die Remote- File Storage for Classic-Replik aus, um den Datenzugriff wiederherzustellen, wenn ein katastrophaler Ausfall den Zugriff auf das Primärvolume unmöglich macht.

Sollte es aufgrund eines katastrophalen Ausfalls oder einer Katastrophe zu einem Ausfall am Primärstandort kommen, können Sie die folgenden Maßnahmen ergreifen, um schnell auf Ihre Daten am Sekundärstandort zuzugreifen. Wenn auf den primären Datenträger nicht zugegriffen werden kann, ist ein Erzwingen eines Failovers auf das ferne Replikat möglich. Bevor Sie das Failover starten, stellen Sie sicher, dass alle Host-Autorisierungen vorliegen.

Autorisierte Hosts und Datenträger müssen sich im selben Rechenzentrum befinden. Wenn sich der Replikatdatenträger beispielsweise in London befindet, kann sich der zugehörige Host nicht in Amsterdam befinden. Beide müssen entweder in London oder in Amsterdam sein.

Sie können die Berechtigung in der Benutzerschnittstelle, über die Befehlszeilenschnittstelle, mit der API oder mit Terraform erstellen.

Diese Aktion unterbricht die Replikationsbeziehung und die Wiederherstellung der Verbindung zwischen der primären und der Replikatposition kann zeitaufwendig sein.

Failover auf das Replikat-Volume in der Konsole

  1. Rufen Sie Ihre File Storage for Classic-Liste auf. Klicken Sie im Menü Infrastruktur VPC-Symbol > Klassische Infrastruktur auf Storage > File Storage for Classic.
  2. Suchen Sie den Namen des Datenträgers und klicken Sie darauf.
  3. Klicken Sie auf Aktionen Aktionssymbol > Failover.
  4. Wenn der primäre Standort deaktiviert ist, wird die Option Disaster Recovery Failover aktiviert.
  5. Klicken Sie auf Ja, um den Vorgang fortzusetzen.

Failover auf das Replikat-Volume über die CLI

Bevor Sie beginnen, entscheiden Sie, welchen CLI-Client Sie verwenden wollen.

Failover über IBMCLOUDCLI einleiten

Sie können den Befehl ibmcloud sl file replica-failover verwenden, um Operationen von der Quellendateifreigabe auf die Replikatdateifreigabe zu übertragen. Im folgenden Beispiel wird ein Failover von der Quellenfreigabe 560156918 auf die Replikatfreigabe 560382016 eingeleitet.

$ ibmcloud sl file file disaster-recovery-failover 560156918 560382016
OK
Failover of volume 560156918 to replica 560382016 is now in progress.

Failover über die SLCLI einleiten

Verwenden Sie den folgenden Befehl für den Failover eines Dateidatenträgers auf einen bestimmten Replikatdatenträger.

$ slcli file disaster-recovery-failover --help
Usage: slcli file disaster-recovery-failover [OPTIONS] VOLUME_ID
Options:
--replicant-id TEXT  ID of the replicant volume
-h, --help           Show this message and exit.

Failover auf das Replikat-Volume über die API

REST-API

  • URL: https://USERNAME:APIKEY@api.softlayer.com/rest/v3/SoftLayer_Network_Storage/primaryvolumeId/disasterRecoveryFailoverToReplicant
  • Anforderungshauptteil
 {
   "parameters": [replicavolumeid]
 }

SOAP-API

  • URL: https://api.softlayer.com/soap/v3/SoftLayer_Network_Storage
  • Anforderungshauptteil
  <?xml version="1.0" encoding="UTF-8"?>
  <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://api.service.softlayer.com/soap/v3.1/">
   <SOAP-ENV:Header>
    <ns1:authenticate>
    <username>USERNAME</username>
    <apiKey>APIKEY</apiKey>
   </ns1:authenticate>
   <ns2:SoftLayer_Network_StorageInitParameters>
    <id>primary Volume Id</id>
   </ns2:SoftLayer_Network_StorageInitParameters>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
    <ns1:disasterRecoveryFailoverToReplicant>
     <replicantId xsi:type="int">replica Volume ID</replicantId>
    </ns1:disasterRecoveryFailoverToReplicant>
   </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

Während des Failovers wegen einer Disaster-Recovery wird die Übernahme des Systems durch den Replikatstandort erzwungen und die Replikationsbeziehung wird unterbrochen. Um nach der Wiederherstellung des normalen Betriebs auf den ursprünglichen Standort zurückwechseln zu können, muss das System die Replikationsverbindung wiederherstellen. Dieser Vorgang kann einige Zeit in Anspruch nehmen. Während des Prozesses der Rückübertragung sind konfigurationsbezogene Aktionen schreibgeschützt. Sie können Snapshotpläne nicht bearbeiten oder Snapshotbereiche ändern. Das Ereignis wird im Replikationsprotokoll protokolliert.

Wenn Sie weitere Hilfe benötigen, erstellen Sie bitte einen Support-Fall.

Rückfall auf den ursprünglichen Primärstandort in der Konsole

Nach einem Katastrophenfall beginnt IBM Cloud® mit Korrekturmaßnahmen, um die betroffenen Standorte wieder in den normalen Betrieb zu bringen. Sobald die Website wiederhergestellt ist, können Sie ein Failback zur ursprünglichen Website einleiten, indem Sie in der IBM Cloud®-Konsole auf Storage und dann auf File Storage for Classic klicken.

  1. Klicken Sie auf Ihren aktiven Datenträger ("Ziel").
  2. Klicken Sie anschließend auf Replik und anschließend auf Aktionen Symbol für Aktionen.
  3. Wählen Sie Rückübertragung aus. Wenn der primäre Standort als deaktiviert markiert ist, wird die Option Disaster Recovery Failback aktiv.

Während des Failovers wegen einer Disaster-Recovery wird die Übernahme des Systems durch den Replikatstandort erzwungen und die Replikationsbeziehung wird unterbrochen. Um nach der Wiederherstellung des normalen Betriebs auf den ursprünglichen Standort zurückwechseln zu können, muss das System die Replikationsverbindung wiederherstellen. Dieser Vorgang kann einige Zeit in Anspruch nehmen. Es wird eine Meldung angezeigt, die darauf hinweist, dass das Failover gerade durchgeführt wird. Darüber hinaus wird neben Ihrem Datenträger auf der File Storage for Classic-Seite ein Symbol angezeigt, das darauf hinweist, dass zurzeit eine Transaktion aktiv ist. Bei Bewegen des Mauszeigers über das Symbol wird die Transaktion in einem Fenster angezeigt. Das Symbol wird ausgeblendet, sobald die Transaktion abgeschlossen ist. Während des Prozesses der Rückübertragung sind konfigurationsbezogene Aktionen schreibgeschützt. Sie können Snapshotpläne nicht bearbeiten oder Snapshotbereiche ändern. Das Ereignis wird im Replikationsprotokoll aufgezeichnet.

  1. Klicken Sie anschließend auf View All File Storage for Classic.
  2. Klicken Sie auf Ihren Replikatdatenträger ("Quelle"). Dieser Datenträger weist nun den Status Inaktiv auf.
  3. Hängen Sie Ihren Speicherdatenträger an den Host an und verbinden Sie ihn. Weitere Informationen finden Sie unter Speicher verbinden.

Wenn Sie weitere Hilfe benötigen, erstellen Sie bitte einen Support-Fall.

Zurücksetzung über die Befehlszeilenschnittstelle

Failback über IBMCLOUDCLI einleiten

Sie können den Befehl ibmcloud sl file replica-failback verwenden, um Operationen von der Replikatdateifreigabe auf die ursprüngliche Quellendateifreigabe zurückzusetzen. Im folgenden Beispiel wird ein Failback auf die ursprüngliche gemeinsam genutzte Quellenressource 560156918 eingeleitet.

$ ibmcloud sl file replica-failback 560156918
OK
Failback of volume 560156918 is now in progress.

Weitere Informationen zu allen für diesen Befehl verfügbaren Parameter finden Sie in ibmcloud sl file replica-failover.

Failback über die SLCLI einleiten

Verwenden Sie den folgenden Befehl, um einen Dateidatenträger von einem bestimmten Replikatdatenträger zurückzusetzen.

$ slcli file replica-failback --help
Usage: slcli file replica-failback [OPTIONS] VOLUME_ID
Options:
 --replicant-id TEXT  ID of the replicant volume
 -h, --help           Show this message and exit.

Während des Failovers wegen einer Disaster-Recovery wird die Übernahme des Systems durch den Replikatstandort erzwungen und die Replikationsbeziehung wird unterbrochen. Um nach der Wiederherstellung des normalen Betriebs auf den ursprünglichen Standort zurückwechseln zu können, muss das System die Replikationsverbindung wiederherstellen. Dieser Vorgang kann einige Zeit in Anspruch nehmen. Während des Prozesses der Rückübertragung sind konfigurationsbezogene Aktionen schreibgeschützt. Sie können Snapshotpläne nicht bearbeiten oder Snapshotbereiche ändern. Das Ereignis wird im Replikationsprotokoll protokolliert.

Wenn der ursprüngliche Datenträger aktiv ist, können Sie ihn an den Host anhängen. Weitere Informationen finden Sie unter Speicher verbinden.

Wenn Sie weitere Hilfe benötigen, erstellen Sie bitte einen Support-Fall.