Begriffe und Definitionen

GRS in Standort des Clients

Die GRS-Aktivierung in IBM Power Virtual Server Private Cloud ermöglicht die asynchrone Replikation von Daten zwischen der Infrastruktur des Primärstandorts und der Infrastruktur des Sekundärstandorts. Die beiden Infrastrukturstandorte verfügen über die gleichen Funktionen, die IBM Power Virtual Server in IBM bietet.

Stellen Sie die Netzwerkkonfiguration zwischen dem primären Standort und dem sekundären Standort für die Replikation bereit, die die folgenden Voraussetzungen umfasst:

• Die Netzwerkbandbreite muss größer oder gleich 10 Gbps sein.
• Die Latenzzeit des Netzes muss kleiner oder gleich 200 ms sein.

Bei der ersten Synchronisierung werden die gesamten Daten von den primären Volumes auf die Hilfsvolumes kopiert. Bei nachfolgenden Synchronisationen werden nur die Änderungen zwischen den beiden Synchronisationsvorgängen kopiert. Das effektive Wiederherstellungsziel (Recovery Point Objective, RPO) hängt von der Leistungsfähigkeit des zugrunde liegenden Netzdurchsatzes und den Anwendungsmerkmalen ab. Wenn der Netzdurchsatz nicht ausreicht, um den festgelegten RPO zu erreichen, erhöht sich die Zeitdauer zwischen den Synchronisierungen.

Wenn das definierte RPO um mehr als 8 Stunden überschritten wird, werden Sie vom IBM Operations Team gewarnt.

Die Replikation zwischen den VMs in IBM Power Virtual Server in der Umgebung IBM und IBM Power Virtual Server Private Cloud in der Umgebung Standort des Clients wird nicht unterstützt.

Preisgestaltung für GRS

Die Teilenummern werden zur Berechnung der Kosten für GRS auf der Grundlage der mit dem primären Datenträger verbundenen Speicherebene verwendet. Weitere Informationen finden Sie unter Preisgestaltung für Global Replication Services(GRS).

Power Virtual Server Regionen, die GRS unterstützen

In der folgenden Tabelle sind die Standortpaare aufgeführt, die die Replikation unterstützen:

Um eine Liste der replikationsfähigen Standortnamen abzurufen, verwenden Sie die folgenden API- oder CLI-Befehle:

• API: Abrufen der Details des Disaster-Recovery-Standorts für den aktuellen Standort

• CLI: ibmcloud pi disaster-recovery. Setzen Sie das Kennzeichen --all-regions auf true.

Überprüfen Sie, ob der primäre und der sekundäre Standort, die für die Replikation verwendet werden sollen, für Replikationsdienste aktiviert sind und in der Liste der replikationsfähigen Paare aufgeführt sind.

Im folgenden Beispiel bilden die Rechenzentren wdc07 und dal10 ein replikationsfähiges Paar:

{
  "location": "dal10",
  "replicationSites": [
    {
      "ReplicationPoolMap": [
        {
          "remotePool": "General-Flash-92",
          "volumePool": "General-Flash-83"
        }
      ],
      "isActive": true,
      "location": "wdc07"
    }
  ]
}

Power Virtual Server speicherpools, die GRS unterstützen

Sie können replikationsfähige Volumes nur aus Speicherpools zuweisen, die Replikation unterstützen. Um die Speicherpools zu identifizieren, die die Replikation unterstützen, verwenden Sie die folgenden API- oder CLI-Befehle:

• API: Speicherkapazität für alle verfügbaren Speicherpools in einer Region

• CLI: ibmcloud pi storage-pools

Wenn ein Speicherpool Replikation unterstützt, wird die Eigenschaft replication-enabled auf true gesetzt.

Wenn Sie ein Volume erstellen, das replikationsfähig ist, wird das Volume standardmäßig in einem der Speicherpools erstellt, die die Replikation unterstützen. Wenn Sie ein Volume aktualisieren möchten, um die Replikation zu aktivieren, müssen Sie sicherstellen, dass Sie es in einem Speicherpool erstellen, der die Replikation unterstützt. Andernfalls schlägt der Aktualisierungsvorgang fehl.

Erstellen einer Volume-Gruppe für GRS

Eine Volume-Gruppe ist eine von Power Virtual Server verwaltete Ressource. Mithilfe der Volume-Gruppe können Sie eine Konsistenzgruppe für die Speicherreplikation aktivieren, deaktivieren und verwalten. Die Volume-Gruppe enthält die Volumes, die zum Zeitpunkt des Desasters wiederhergestellt werden müssen. Sie können die replikationsfähigen Volumes zu einer Volume-Gruppe hinzufügen. Ein replikationsfähiges Volume kann jeweils nur Teil einer Volume-Gruppe sein. Darüber hinaus müssen alle Volumes in einer Volume-Gruppe Teil desselben Speicherpools sein.

Wenn Sie eine Volume-Gruppe am primären Speicherort erstellen, wird die Speicherreplikations-Konsistenzgruppe im Speicher-Backend sowohl am primären als auch am sekundären Speicherort erstellt. Die Konsistenzgruppe der Speicherreplikation speichert die konsistente Kopie für die Volumes in der Volume-Gruppe. Um Operationen an der Konsistenzgruppe durchzuführen, müssen Sie die Operation an der Volume-Gruppe durchführen, die die Konsistenzgruppe repräsentiert. Power Virtual Server verwaltet die Konsistenzgruppe nicht direkt im Speicher-Backend. Ein Speicher-Backend ist das Speichersubsystem, das den Speicherpool und den Speicher-Controller enthält.

Wenn Sie ein Volume am sekundären Speicherort einbinden und die Volume-Gruppe noch nicht erstellt wurde, wird das Volume erstellt und das eingebundene Hilfsvolume wird hinzugefügt. Diese Volume-Gruppe wird von Power Virtual Server am sekundären Speicherort angezeigt und verwaltet. Weitere Informationen finden Sie unter Onboarding eines Zusatzvolumes.

Bei der ersten Datensynchronisation werden die gesamten Daten des primären Datenträgers auf die zusätzlichen Datenträger kopiert. Bei nachfolgenden Datensynchronisationen werden nur die Änderungen zwischen den beiden Synchronisationsvorgängen kopiert. Das effektive Wiederherstellungsziel (Recovery Point Objective, RPO) hängt von der Leistungsfähigkeit des Netzdurchsatzes und den Anwendungsmerkmalen ab. Wenn der Netzwerkdurchsatz nicht ausreicht, um das definierte RPO einzuhalten, erhöht sich die Dauer zwischen den Datensynchronisationen.

Eine Volume-Gruppe wird zum Aktivieren, Deaktivieren und Verwalten einer replikationsaktivierten Konsistenzgruppe in Speicher-Volumes verwendet. Durch die Verwendung einer Konsistenzgruppe können Sie Vorgänge auf mehreren Volumes durchführen, anstatt jedes Volume einzeln zu verwalten. Die Konsistenzgruppe hat eine state Eigenschaft, die den Status des copy Vorgangs der Volumes in der Gruppe angibt.

In der folgenden Tabelle sind die verschiedenen Zustände der replikationsaktivierten Konsistenzgruppe in Speicher-Volumes aufgeführt.

Wenn Sie einen Vorgang an einer Volume-Gruppe an einem Speicherort durchführen, wirkt sich dies auf die zugehörige Volume-Gruppe am anderen Speicherort aus. Nehmen wir zum Beispiel an, eine Volume-Gruppe wird an einem primären Speicherort angehalten. Nach einiger Zeit wird die zugehörige Volume-Gruppe am sekundären Speicherort aktualisiert, um den Replikationsstatus des Paares in der Volume-Gruppe wiederzugeben. In diesem Fall zeigt das Feld replicationStatus den Status der Volume-Gruppe als disabled sowohl am primären als auch am sekundären Speicherort an.

Bevor Sie einen Vorgang an einer Volume-Gruppe an einem Standort durchführen, sollten Sie den Replikationsstatus der Volume-Gruppen am primären und sekundären Standort überprüfen.

Sie können die replikationsfähigen Volumes gruppieren, die in ihrer Funktion ähnlich sind. So können beispielsweise Volumes, die einem bestimmten Workload zugeordnet sind, in einer Volume-Gruppe zusammengefasst werden. Wenn zusätzliche replikationsfähige Volumes erstellt werden, können Sie ein Volume zu einer bestehenden Volume-Gruppe mit ähnlichen Volumes auf der Grundlage der Funktion hinzufügen. Sie können eine neue Volume-Gruppe für die Volumes erstellen, wenn deren Funktion nicht mit der der vorhandenen Volumes übereinstimmt.

Vorbereitung auf Disaster-Recovery

Stellen Sie sich vor, Sie haben virtuelle Serverinstanzen mit Datenträgern, auf denen Arbeitslasten ausgeführt werden. Wenn ein Fehler auftritt und die Data-Volumes repliziert sind, können Sie die Data-Volumes vom sekundären Speicherort wiederherstellen. Um den Volume-Replikationsdienst zu aktivieren, führen Sie die folgenden Aktionen durch:

• Aktionen am Hauptstandort
• Aktionen am sekundären Standort

Sie müssen die Aktionen auf der primären Site abschließen, bevor Sie mit den Aktionen auf der sekundären Site fortfahren.

Durchführung eines Failover- und Fallback-Vorgangs

Tritt am primären Standort eine Katastrophe ein, geht der Zugriff auf alle am primären Standort zugewiesenen Speichervolumes verloren. Die Replikationsbeziehung für die replikationsfähigen primären Volumes mit dem sekundären Speicherort ist unterbrochen. Der Status der Konsistenzgruppe (Volume-Gruppe) ändert sich zu inconsistent-disconnected. Am primären Speicherort ist kein Volume mit der primären Rolle in der Volume-Gruppe verbunden.

Führen Sie die folgenden Schritte aus, um die Failover-Vorgänge am sekundären Standort durchzuführen:

1. Beenden Sie die Hilfsvolume-Gruppe und greifen Sie auf das Hilfsvolume am sekundären Speicherort zu. Siehe, Failover zum sekundären Standort
2. Überprüfen Sie, ob sich die Gruppe der Hilfsvolumes im Leerlauf befindet

Wenn Sie die Failover-Schritte abgeschlossen haben, sind die Volumes bereit, E/A-Anforderungen zu akzeptieren. Die virtuelle Serverinstanz, an die diese Volumes angehängt sind, kann eingeschaltet werden und Sie können die Ausführung fortsetzen.

    Request Body:
    {
      "start": {
        "source": "aux"
      }
    }

    Request Body:
    {
      "stop": {
        "access": true
      }
    }

    Request Body:
    {
      "start": {
        "source": "master"
      }
    }

Aktualisieren eines vorhandenen Volumes als replikationsfähiges Volume

Sie können ein vorhandenes Volume so ändern, dass es replikationsfähig ist, wenn es in einem Speicherpool erstellt wurde, der den Replikationsprozess unterstützt. Um dies zu überprüfen, fragen Sie die Details des Volumes ab, rufen Sie die Details des Speicherpools ab, der das Volume enthält, und überprüfen Sie es mit der Liste der Speicherpools, die Replikation unterstützen. Weitere Informationen zu Speicherpools, die Replikation unterstützen, finden Sie unter Power Virtual Server storage pool that supports GRS.

Verwenden Sie die folgenden API- und CLI-Befehle zur Abfrage der Volume-Details:

• API: Ausführen einer Aktion für eine Volume-Gruppe. Setzen Sie den Parameter VOLUME_ID auf die primäre Volume-ID. Verwenden Sie die API, um die Volume-Details wie im folgenden Code definiert abzufragen:

    Request Body:
    {
      "replicationEnabled": true
    }

• CLI: ibmcloud pi volume-group Aktion. Setzen Sie den Parameter VOLUME_ID auf die ID des Primärdatenträgers, und fragen Sie ab, ob das Kennzeichen --replication-enabled auf True gesetzt ist.

Hinzufügen eines replikationsfähigen Volumes zu einer vorhandenen Volume-Gruppe

Sie können replikationsfähige Volumes mit den folgenden API- und CLI-Befehlen zu einer bestehenden Volume-Gruppe hinzufügen:

• API: aktualisiert die Volume-Gruppe. Setzen Sie den Parameter VOLUME_GROUP_ID auf die primäre Volume-Gruppen-ID. Fügen Sie mithilfe der API die IDs der primären Datenträger zur Datenträgergruppe hinzu, wie im folgenden Code definiert:

    Request Body:
    {
      "addVolumes": [
        "PRIMARY_VOLUME_ID"
      ]
    }

• CLI: ibmcloud pi volume-group update. Setzen Sie den Parameter VOLUME_GROUP_ID auf die ID der primären Datenträgergruppe und setzen Sie das Kennzeichen --add-member-ids auf die IDs der primären Datenträger, die der Datenträgergruppe hinzugefügt werden müssen.

Deaktivieren der Replikation eines Volumes

Wenn Sie die Replikation eines primären Volumes deaktivieren, wird das zugehörige Hilfsvolume am sekundären Speicherort gelöscht.

Wenn Sie diesen Vorgang nicht in der angegebenen Reihenfolge durchführen, kann dies zum Verlust von Quellvolumendaten führen. Zuerst müssen Sie die Aktionen am primären Standort und dann die Aktionen am sekundären Standort abschließen.

Um die Replikation eines primären Volumes zu deaktivieren, führen Sie die folgenden Schritte aus:

1. Aktionen am Hauptstandort

   1. Entfernen Sie das primäre Volume aus der Volume-Gruppe
   2. Löschen Sie die primäre Volume-Gruppe, falls leer
   3. Deaktivieren der Replikation für das primäre Volume
   4. Überprüfen Sie, ob die Replikation für das primäre Volume deaktiviert ist

2. Aktionen am sekundären Standort

Sie können diese Schritte nur durchführen, wenn Sie den Einrichtungsvorgang des Zusatzdatenträgers abgeschlossen haben.

1. Entfernen Sie das Zusatzvolume aus der Volume-Gruppe
2. Löschen Sie die zusätzliche Volume-Gruppe, falls sie leer ist
3. Löschen Sie das Zusatzvolumen

    Request Body:
    {
      "removeVolumes": [
        "PRIMARY_VOLUME_ID"
      ]
    }

    Request Body:
    {
      "replicationEnabled": false
    }

    Request Body:
    {
      "removeVolumes": [
        "AUXILIARY_VOLUME_ID"
      ]
    }

Ändern eines replikationsaktivierten primären Volumes

Sie können die Attribute eines replikationsaktivierten primären Volumes ändern. Um einige der Eigenschaften der primären und sekundären Volumes zu ändern, müssen Sie entsprechende Aktionen an den primären und sekundären Speicherorten durchführen.

  Request Body:
  {
    "size": SIZE_IN_GB
  }

Ändern der bootfähigen und gemeinsam nutzbaren Eigenschaften eines primären Volumes

Um die Werte der Eigenschaften bootable oder shareable auf dem primären Volume zu ändern, verwenden Sie die folgenden API- oder CLI-Befehle:

• API: Aktualisieren Sie ein Cloud-Instance-Volumen. Setzen Sie den Parameter VOLUME_ID auf die ID des primären Datenträgers und setzen Sie die Flags --bootable oder --shareable auf den Wert True oder False.

• CLI: ibmcloud pi volume update. Setzen Sie den Wert des Parameters VOLUME_ID auf die ID des primären Datenträgers und setzen Sie den Wert des Flags --bootable oder --shareable auf den Wert True oder False.

Ein Volume kann entweder gemeinsam genutzt werden oder bootfähig sein, aber nicht beides.

Nachdem Sie die Eigenschaftswerte bootable oder shareable für ein primäres Volume am primären Speicherort geändert haben, müssen Sie dieselbe Eigenschaft für das zusätzliche Volume am sekundären Speicherort aktualisieren.

Ändern der Ebene eines primären Datenträgers

Sie können die Ebene eines replikationsaktivierten Volumes nicht ändern.

Löschen eines replikationsaktivierten primären Volumes

Um ein Volume oder ein replikationsfähiges primäres Volume zu löschen, muss der Status des Volumes einen der folgenden Zustände anzeigen: available, error, error_restoring, error_extending, oder error_managing. Darüber hinaus können Sie das Volume nicht löschen, wenn es sich im Status migrating oder attached befindet, zu einer Volume-Gruppe gehört, Snapshots hat oder nach einer Übertragung von seinen Snapshots getrennt wird.

Um ein primäres Volume zu löschen, müssen Sie die Aktionen an den primären und sekundären Speicherorten durchführen:

• Führen Sie die folgenden Aktionen am primären Standort durch:

  1. Entfernen des primären Volumes aus seiner Volume-Gruppe, wenn das primäre Volume mit einer Volume-Gruppe verbunden ist
  2. Löschen Sie das primäre Volume

• Führen Sie die folgenden Aktionen am sekundären Speicherort durch, wenn der Zusatzdatenträger am sekundären Speicherort eingefügt ist:

  1. Entfernen eines Hilfsvolumes aus seiner Volume-Gruppe, wenn das Hilfsvolumen mit einer Volume-Gruppe verbunden ist
  2. Löschen Sie das Zusatzvolumen

Wenn das Hilfsvolume nicht vom sekundären Standort gelöscht wird, wird das Hilfsvolume durch eine periodische Out-of-Band-Prüfung, die alle 24 Stunden stattfindet, in den Zustand ERROR versetzt. Sie können ein Volume nicht verwenden, wenn es sich im Zustand ERROR befindet, und der einzige Vorgang, den Sie durchführen können, ist das Löschen des Volumes.

    Request Body:
    {
      "removeVolumes": [
        "PRIMARY_VOLUME_ID"
      ]
    }

Löschen eines replikationsaktivierten Hilfsvolumes

Wenn Sie ein Hilfsvolume löschen, wird auch das zugehörige Hauptvolume gelöscht.

Wenn Sie den Replikationsdienst auf dem primären Volume deaktivieren oder das primäre Volume löschen, wird die Replikationsbeziehung zwischen dem primären Volume und dem sekundären Volume im Speicher-Backend gelöscht. Wenn das Hilfsvolume am sekundären Speicherort mit einer Volume-Gruppe verbunden ist, entfernen Sie das Hilfsvolume aus der Volume-Gruppe. Löschen Sie das Zusatzvolumen manuell. Wenn Sie das Zusatzvolume nicht vom sekundären Standort löschen, wird das Zusatzvolume durch eine periodische Out-of-Band-Prüfung, die alle 24 Stunden stattfindet, in den Zustand ERROR versetzt. Bestätigen Sie den Status des Hilfsvolumens, indem Sie die Eigenschaft outOfBandDeleted des Hilfsvolumens überprüfen.

Auswirkungen der GRS auf andere Operationen Power Virtual Server

Die Auswirkungen von GRS auf andere Power Virtual Server Vorgänge sind wie folgt:

• Die Bildschnittstelle wird nicht geändert und die Replikation wird für Bilder nicht unterstützt
• Die Betriebsschnittstelle und die Affinitätsrichtlinien für den Speicherpool für virtuelle Serverinstanzen werden nicht geändert. Die für die Replikation und nicht für die Replikation aktivierten Datenträger unterstützen das Anhängen und Abhängen von Datenträgern.
• Snapshot-und Erfassungsoperationen sind für eine virtuelle Serverinstanz mit Replikation und nicht für die Replikation aktivierten Datenträgern zulässig, wenn die Datenträger aus demselben Speicherpool stammen. Die Momentaufnahme-und Erfassungsoperationen werden intern mithilfe der nicht für die Replikation aktivierten Datenträger ausgeführt, obwohl die Datenträger einer virtuellen Serverinstanz für die Replikation aktiviert sind.
• Das geklonte Volume ist standardmäßig replikationsaktiviert, wenn Sie ein replikationsaktiviertes Volume klonen. Beim Klonen können Sie angeben, ob das geklonte Volume replikationsfähig sein muss oder nicht. Wenn das geklonte Volume replikationsfähig sein soll, geben Sie die Richtlinie für das geklonte Volume an. Sie können die folgenden Methoden verwenden, um ein Volume zu klonen:
  • Klonen eines Datenträgers über die API.
  • Klonen eines Volumes mit CLI.
  • Klonen Sie ein Volume mit Terraform.

Bewährte Praktiken für GRS

• Setzen Sie bei Bedarf explizit die Flagge für " Shareable" und " Bootable" auf Onboard-Volumes.
• Starten Sie das Onboarding von Hilfsvolumes erst, wenn sich die primären Volumes und die Volume-Gruppe in einem konsistenten Kopierzustand befinden. Sie können die Volume-Details abrufen, indem Sie die API get volume verwenden, um den Status der primären Volumes und der Volume-Gruppe im Spiegelungsstatus auf der primären Site zu ermitteln. Überprüfen Sie, ob die Volume-Gruppe erfolgreich erstellt wurde und sich in einem konsistenten Kopierzustand befindet, indem Sie die Speicherdetails der Volume-Gruppe-API abrufen.

• Sie können mit den folgenden Methoden Details zum Volumen abrufen:
  • Power Cloud API.
  • Terraform.
• Rufen Sie die Speicherdetails der Volume-Gruppen mit Hilfe der folgenden Methoden ab:
  • Power Cloud API.
  • Power Virtual Server CLI
  • Terraform.

• Wenn Sie ein primäres oder zusätzliches Volume einer Volume-Gruppe von einem Speicherort aus hinzufügen oder entfernen, führen Sie denselben Vorgang am anderen Speicherort durch, um die Daten zu synchronisieren.
• Löschen Sie die Volumes vom primären und sekundären Speicherort. Volumes werden belastet, wenn Sie ein Hilfsvolume löschen, aber das primäre Volume nicht löschen.
• Verwenden Sie den primären Speicherort für alle Volume-Vorgänge und führen Sie Vorgänge auf dem Hilfsvolume am sekundären Speicherort nur während des Failovers durch.