Volumes asynchron replizieren

Auf dieser Seite erfahren Sie, wie Sie die asynchrone Replikation von Blockspeicher-Volumes in Google Distributed Cloud (GDC) mit Air Gap 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 so eingerichtet werden, dass es auf dasselbe Ziel-Volume repliziert wird. Stattdessen muss eine neue Replikationsbeziehung erstellt werden.

Anwendungsexperten, die die gdcloud-Befehlszeile bevorzugen, finden weitere Informationen unter Volumes asynchron für Anwendungsexperten replizieren.

Hinweis

Damit Sie die asynchrone Blockreplikation verwenden können, muss Ihr Infrastrukturoperator (IO) zuerst zwei Zonen für die asynchrone Replikation einrichten.

Prüfen Sie als Nächstes, ob Sie die Rolle volume-replication-admin-global zum Verwalten der VolumeReplicationRelationship-Ressource haben. 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 (CR) „VolumeReplicationRelationship“ stellt die API für die asynchrone Blockreplikation bereit. Diese CR ist in der globalen Management API vorhanden. Damit die Replikation für ein bestimmtes blockorientiertes Gerät aktiviert werden kann, muss eine VolumeReplicationRelationship-CR in der globalen Verwaltungs-API erstellt werden:

PVC API

Projektbindung ist erforderlich. Achten Sie darauf, dass Sie Ihr Projekt an jede Clusterressource in jeder teilnehmenden Zone angehängt haben.

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    pvc:
      clusterRef: SOURCE_USER_CLUSTER_NAME
      pvcRef: PVC_NAME
    zoneRef: SOURCE_ZONE_NAME
  destination:
    pvc:
      clusterRef: DESTINATION_USER_CLUSTER_NAME
    zoneRef: DESTINATION_ZONE_NAME
EOF

Ersetzen Sie Folgendes:

• MANAGEMENT_API_SERVER: der kubeconfig-Pfad des zonalen API-Servers.
• VRR_NAME: der Name der VolumeReplicationRelationship-Ressource.
• PROJECT: der Namespace der Projektressource.
• SOURCE_USER_CLUSTER_NAME: der Name der zu verbindenden Quellnutzercluster-Ressource.
• PVC_NAME: der Name der PersistentVolumeClaim-Ressource.
• SOURCE_ZONE_NAME: der Name der Quellzonenressource.
• DESTINATION_USER_CLUSTER_NAME: der Name der Zielnutzercluster-Ressource, die verbunden werden soll.
• DESTINATION_ZONE_NAME: der Name der Zielzonenressource.

In diesem Beispiel wird davon ausgegangen, dass ein Projekt mit dem Namen PROJECT in einer Organisation mit dem Namen my-org erstellt wurde und dass bereits ein PVC mit dem Namen PVC_NAME bereitgestellt wurde. SOURCE_USER_CLUSTER_NAME ist der Name des Quellclusters, auf dem der PVC vorhanden ist, und DESTINATION_USER_CLUSTER_NAME ist der Name des Zielclusters, auf dem ein neuer PVC vorhanden sein wird.

Die Felder source und destination der Spezifikation geben an, von wo und wohin die Daten repliziert werden. In diesem Beispiel werden die Daten von SOURCE_ZONE_NAME nach DESTINATION_ZONE_NAME repliziert.

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

VM Disk API

VM-Laufwerke replizieren

VolumeReplicationRelationship bedient auch die API für die asynchrone Replikation von VM-Laufwerken. Das Quelllaufwerk, das repliziert wird, wird als primäres Laufwerk bezeichnet. Das Ziellaufwerk, auf das repliziert wird, wird als sekundäres Laufwerk bezeichnet. Wenn Sie die asynchrone Replikation auf einem primären Laufwerk starten, wird das sekundäre Laufwerk automatisch erstellt.

Berechtigungen und Zugriff anfordern

Zum Replizieren von VM-Laufwerken benötigen Sie die Rolle „Project VirtualMachine Admin“. Folgen Sie der Anleitung, um zu prüfen, ob Sie die Rolle „Project VirtualMachine Admin“ (project-vm-admin) im Namespace des Projekts haben, in dem sich das VM-Laufwerk befindet.

Bitten Sie für VM-Vorgänge mit der gdcloud CLI Ihren IAM-Projektadministrator, Ihnen sowohl die Rolle „Project VirtualMachine Admin“ als auch die Rolle „Project Viewer“ (project-viewer) zuzuweisen.

Asynchrone Replikation starten

Asynchrone Replikation auf einem VM-Laufwerk mit kubectl starten.

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  destination:
    volumeOverrideName: VIRTUAL_MACHINE_DESTINATION_DISK_NAME
    zoneRef: DESTINATION_ZONE_NAME
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: VIRTUAL_MACHINE_SOURCE_DISK_NAME
    zoneRef: SOURCE_ZONE_NAME
EOF

Ersetzen Sie Folgendes:

• MANAGEMENT_API_SERVER: der kubeconfig-Pfad des zonalen API-Servers.
• VRR_NAME: der Name der VolumeReplicationRelationship-Ressource.
• PROJECT: der Namespace der Projektressource.
• SOURCE_ZONE_NAME: der Name der Quellzonenressource.
• DESTINATION_ZONE_NAME: der Name der Zielzonenressource.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: der Name der VirtualMachineDisk-Ressource in der Quelle.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: der Name der VirtualMachineDisk-Ressource am Ziel.

In diesem Beispiel wird davon ausgegangen, dass ein Projekt mit dem Namen PROJECT in einer Organisation mit dem Namen my-org erstellt wurde und dass bereits ein VirtualMachineDisk mit dem Namen VIRTUAL_MACHINE_SOURCE_DISK_NAME für die Ressource VirtualMachine bereitgestellt wurde.

Die Felder source und destination der Spezifikation geben an, von wo und wohin die Daten repliziert werden. In diesem Beispiel werden die Daten von SOURCE_ZONE_NAME nach DESTINATION_ZONE_NAME repliziert.

Hinweis: Der asynchrone Blockreplikationsdienst erstellt automatisch eine VirtualMachineDisk in der Zielzone, um die replizierten Daten zu schreiben. Standardmäßig hat diese VirtualMachineDisk denselben Namen wie die Quell-VirtualMachineDisk. Mit dem Feld volumeOverrideName kann jedoch der Name der erstellten VirtualMachineDisk angegeben werden. Bis ein VolumeReplicationFailover erstellt wird, bleibt das Ziel-VirtualMachineDisk jedoch schreibgeschützt und kann von keinen Arbeitslasten bereitgestellt werden.

Überprüfung

Prüfen Sie den Status der Replikationsbeziehung, indem Sie die VolumeReplicationRelationship-CR von der globalen API abrufen. Siehe folgendes Beispiel. Die Ausgabe wurde zur Vereinfachung gekürzt:

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
        -n PROJECT -o yaml

Die Ausgabe sieht etwa so aus:

PVC API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: 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: 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

VM Disk API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: 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: 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

Wenn die Quellzone aus irgendeinem Grund nicht verfügbar ist, kann in der Verwaltungsebene der Organisation der Zielzone eine VolumeFailover-CR erstellt werden. Bei einer v2-Organisation wäre dies der Management API-Server. Bei einer v1-Organisation wäre dies der Administratorcluster der Organisation. Wenn beispielsweise ein VolumeReplicationRelationship erstellt wurde, das zone2 als Zielzone angibt, und ein PVC oder VirtualMachineDisk in der Organisation my-org vorhanden ist, wird die VolumeFailover-CR in der Verwaltungsebene my-org in zone2 erstellt. Dadurch wird die Replikationsbeziehung zwischen den beiden Zonen unterbrochen und der PVC oder die VirtualMachineDisk in der Zielzone kann von einer Arbeitslast bereitgestellt werden:

  kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
  apiVersion: storage.gdc.goog/v1
  kind: VolumeFailover
  metadata:
    name: FAILOVER_NAME
    namespace: PROJECT
  spec:
    volumeReplicationRelationshipRef: VRR_NAME
  EOF

Ersetzen Sie Folgendes:

• FAILOVER_NAME: der Name der VolumeFailover-Ressource.
• MANAGEMENT_API_SERVER: der kubeconfig-Pfad des zonalen API-Servers.
• VRR_NAME: der Name der VolumeReplicationRelationship-Ressource.

• PROJECT: der Namespace der Projektressource.

• Danach wird ein erfolgreiches Failover im Status der benutzerdefinierten Ressource angezeigt:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumefailover FAILOVER_NAME \
          -n PROJECT -o yaml
  

• Die Ausgabe sieht etwa so aus:

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

• Nachdem das Failover erstellt wurde, wechselt die VolumeReplicationRelationship my-vrr-repl in den Status Broken Off. Der PVC oder die VirtualMachineDisk in zone2 kann jetzt bereitgestellt werden.

• An dieser Stelle sieht die VolumeReplicationRelationship in etwa wie das folgende Beispiel aus. Auch diese Ausgabe wurde zur Vereinfachung gekürzt:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
          -n PROJECT -o yaml
  

• Die Ausgabe sieht etwa so aus:

PVC API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vrr-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: 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

VM Disk API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: 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 kann die VolumeReplicationRelationship gelöscht werden, da dies die einzige verbleibende Aktion ist, die für diese benutzerdefinierte Ressource ausgeführt werden kann.

  kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationship VRR_NAME \
          -n PROJECT
  

Größe von Volumes anpassen

Wenn die Größe des Quell-Volumes zu einem beliebigen Zeitpunkt geändert wird, sollte auch die Größe des entsprechenden Volumes in der Zielzone, das im Namen des Nutzers erstellt wird, wenn ein VolumeReplicationRelationship erstellt wird, entsprechend angepasst werden.

Informationen zum Ändern der Speichergröße in Quell- und Zielzonen finden Sie in der Dokumentation unter VM-Laufwerke erweitern oder Volume-Kapazität erweitern.