Volumes asynchron replizieren

Auf dieser Seite erfahren Sie, wie Sie die asynchrone Replikation von Google Distributed Cloud-Block-Storage-Volumes (GDC) einrichten und ausführen.

Die asynchrone Replikation wird verwendet, um Daten von einer GDC-Zone in eine andere zu replizieren. Diese replizierten Daten können in einem Failover-Szenario verwendet werden, falls die Daten in der Quellzone nicht verfügbar sind. Nachdem ein Failover erstellt wurde, kann das ursprüngliche Volume nicht mehr für die Replikation auf dasselbe Zielvolume eingerichtet werden. Stattdessen muss eine neue Replikationsbeziehung erstellt werden.

Hinweise

Wenn Sie die asynchrone Blockreplikation verwenden möchten, muss Ihr Infrastrukturbetreiber (Infrastructure Operator, IO) zuerst die Speicherinfrastruktur zwischen den beiden Zonen einrichten, in denen die Replikation erforderlich ist. Dazu müssen sie zuerst die relevanten Speichercluster aus jeder Zone peeren. Als Nächstes muss die Storage-VM, die der Organisation zugeordnet ist, in der der Blockspeicher bereitgestellt wird, per Peering verbunden werden.

Prüfen Sie anschließend, ob Sie die Rolle volume-replication-admin-global haben, um die Ressource „VolumeReplicationRelationship“ zu verwalten. Wenn die globale API nicht verfügbar ist, kann die Rolle app-volume-replication-admin verwendet werden, um die zonale VolumeReplicationRelationshipReplica-Ressource direkt zu ändern.

Replikation einrichten

Die benutzerdefinierte Ressource (Custom Resource, CR) „VolumeReplicationRelationship“ stellt die asynchrone API für die Blockreplikation bereit. Diese Antwortvorlage ist in der globalen Management API vorhanden. Damit die Replikation für ein bestimmtes Blockgerät aktiviert werden kann, muss in der globalen Management-API ein VolumeReplicationRelationship-CR erstellt werden:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
 destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2

In diesem Beispiel wird davon ausgegangen, dass ein Projekt mit dem Namen my-project in einer Organisation mit dem Namen my-org erstellt wurde und dass ein PVC mit dem Namen my-block-pvc bereits bereitgestellt wurde. clusterRef ist der Name des Clusters, in dem der PVC vorhanden ist.

Die Felder source und destination der Spezifikation geben an, von und nach wo die Daten repliziert werden. In diesem Beispiel werden die Daten von xx-xxxx-zone1 nach xx-xxxx-zone2 repliziert.

Hinweis :Der asynchrone Dienst zur Blockreplikation erstellt automatisch einen PVC in der Zielzone, in den die replizierten Daten geschrieben werden. Standardmäßig hat diese PVC denselben Namen wie die Quell-PVC. Mit dem Feld VolumeOverrideName kann jedoch der Name der erstellten PVC angegeben werden. Bis ein VolumeReplicationFailover erstellt wird, bleibt der Ziel-PVC jedoch schreibgeschützt und kann von keinen Arbeitslasten bereitgestellt werden.

Prüfen Sie den Status der Replikationsbeziehung, indem Sie die VolumeReplicationRelationship-CR aus der globalen API abrufen. Sehen Sie sich das folgende Beispiel an. Die Ausgabe wurde zur Vereinfachung gekürzt:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-zone1
    replicaStatus:
      message: SnapMirror relationship has been established. Please check the destination
        zone for relationship state
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Established
  - name: xx-xxxx-zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been successfully established
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Idle

Failover erstellen

Falls die Quellzone aus irgendeinem Grund nicht verfügbar ist, kann in der Verwaltungsebene der Zielzone der Organisation ein VolumeFailover-CR erstellt werden. Bei einer Organisation der Version 2 ist das der Management API-Server. In einer v1-Organisation ist dies der Administratorcluster der Organisation. Wenn beispielsweise eine VolumeReplicationRelationship erstellt wurde, in der xx-xxxx-zone2 als Zielzone angegeben ist, und ein PVC in der Organisation my-org vorhanden ist, wird die benutzerdefinierte Ressource „VolumeFailover“ in der Steuerungsebene my-org in xx-xxxx-zone2 erstellt. Dadurch wird die Replikationsbeziehung zwischen den beiden Zonen unterbrochen und der PVC in der Zielzone kann von einer Arbeitslast bereitgestellt werden:

apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: my-pvc-failover
  namespace: my-project
spec:
  volumeReplicationRelationshipRef: my-pvc-repl

Nach einem erfolgreichen Failover wird dies im Status der benutzerdefinierten Ressource angezeigt:

apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: my-pvc-failover
  namespace: my-project
spec:
  volumeReplicationRelationshipRef: my-pvc-repl
status:
    state: Completed

Nachdem das Failover erstellt wurde, wechselt die my-pvc-repl-VolumeReplicationRelationship in den Status Broken Off. Das PVC in xx-xxxx-zone2 kann jetzt gemountet werden.

An diesem Punkt sieht die VolumeReplicationRelationship in etwa so aus: Die Ausgabe wurde der Einfachheit halber gekürzt:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: xx-xxxx-zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off

Jetzt können Sie die VolumeReplicationRelationship sicher löschen, da dies die einzige verbleibende Aktion ist, die für diese benutzerdefinierte Ressource ausgeführt werden kann.

Größe von Volumes ändern

Wenn das Quell-Volume zu einem beliebigen Zeitpunkt in der Größe geändert wird, sollte das entsprechende Volume in der Zielzone, das im Namen des Nutzers erstellt wird, wenn eine VolumeReplicationRelationship erstellt wird, ebenfalls in der Größe geändert werden.