IBM Cloud Docs
Disaster-Recovery - Failover über einen nicht zugänglichen Primärdatenträger

Disaster-Recovery - Failover über einen nicht zugänglichen Primärdatenträger

Wenn eine Betriebsunterbrechung oder eine Katastrophe einen Ausfall am primären Standort verursachen, können Kunden die folgenden Aktionen ausführen, um schnell am sekundären Standort auf ihre Daten zuzugreifen. Wenn auf den primären Datenträger nicht zugegriffen werden kann, ist ein Erzwingen eines Failovers auf das ferne Replikat möglich.

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.

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. Navigieren Sie zur IBM Cloud® Block Storage for Classic-Liste. Klicken Sie im Menü Klassische Infrastruktur Symbol 'Klassisch' auf Speicher > Block Storage for Classic.
  2. Suchen Sie den Namen des Datenträgers und klicken Sie darauf.
  3. Klicken Sie auf Aktionen Aktionssymbol> Failover.
  4. Wenn die primäre Position nicht verfügbar ist, wird die Option ‚Notfallwiederherstellung-Failover‘ aktiviert. Wählen Sie das Kontrollkästchen aus, mit dem Sie bestätigen, dass Sie darüber informiert sind, dass der Failover nur über einen Supportfall rückgängig gemacht werden kann.
  5. Klicken Sie auf Ja, um den Vorgang fortzusetzen.

Failover auf das Replikat-Volume vom CLI

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

Failover über IBMCLOUDCLI einleiten

Sie können den Befehl ibmcloud sl block 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 block 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, um einen Failover für einen Blockdatenträger auf einen bestimmten Replikatdatenträger durchzuführen.

$ slcli block disaster-recovery-failover --help
Usage: slcli block disaster-recovery-failover [OPTIONS] VOLUME_ID

Options:
--replicant-id TEXT  ID of the replicant volume
 -h, --help           Show this message and exit.

Failover auf den Replikatdatenträger ü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>

Rückfall auf die ursprüngliche primäre Site in der Konsole

Nach einem Katastrophenfall beginnt IBM Cloud® mit Korrekturmaßnahmen, um die betroffenen Standorte wieder in den normalen Betrieb zu bringen. Wenn die Website wiederhergestellt ist, können Sie ein Failback auf die ursprüngliche Website einleiten, indem Sie auf **"Speicher" **Block Storage for Classic in der IBM Cloud®-Konsole.

  1. Klicken Sie auf Ihren aktiven Datenträger ("Ziel").

  2. Klicken Sie anschließend auf "Replikat" und dann auf "Aktionen ".

  3. Wählen Sie Rückübertragung aus. Wenn der primäre Standort als nicht verfügbar markiert ist, wird die Option 'Disaster Recovery Failback' aktiviert.

    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 die ursprüngliche Website zurückgreifen zu können, muss das System die Replikationsverbindung wiederherstellen. Dieser Vorgang kann sehr viel Zeit in Anspruch nehmen. Es wird die Nachricht angezeigt, dass die Rückübertragung in Bearbeitung ist. Außerdem wird neben Ihrem Datenträger auf dem Block Storage for Classic ein Symbol angezeigt, das angibt, dass eine aktive Transaktion läuft. 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.

  4. Klicken Sie als Nächstes auf Alle anzeigen Block Storage for Classic.

  5. Klicken Sie auf Ihren Replikatdatenträger ("Quelle"). Dieser Datenträger weist nun den Status Inaktiv auf.

  6. Hängen Sie Ihren Speicherdatenträger an den Host an und verbinden Sie ihn. Weitere Informationen finden Sie unter Speicher verbinden.

Wenn Sie weitere Unterstützung benötigen, erstellen Sie einen Supportfall.

Failback von der CLI

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

$ slcli block replica-failback --help
Usage: slcli block 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 die ursprüngliche Website zurückgreifen zu können, muss das System die Replikationsverbindung wiederherstellen. Dieser Vorgang kann sehr viel 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 Unterstützung benötigen, erstellen Sie einen Supportfall.