Volumes asynchron replizieren

Auf dieser Seite erfahren Sie, wie Sie die asynchrone Replikation von Google Distributed Cloud-Blockspeicher-Volumes (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 für die Replikation auf dasselbe Zielvolume eingerichtet werden. Stattdessen muss eine neue Replikationsbeziehung erstellt werden.

Anwendungsoperatoren, die lieber die gdcloud-Befehlszeile verwenden, finden weitere Informationen unter Volumes asynchron replizieren.

Hinweis

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

Prüfen Sie als Nächstes, 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:

PVC API

Projektbindung ist erforderlich. Verknüpfen Sie Ihr Projekt mit jeder Clusterressource in jeder teilnehmenden Zone.

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 Quellnutzerclusterressource, die verbunden werden soll.
• PVC_NAME: Der Name der PersistentVolumeClaim-Ressource.
• SOURCE_ZONE_NAME: Der Name der Quellzonenressource.
• DESTINATION_USER_CLUSTER_NAME: Der Name der Zielnutzerclusterressource, 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 ein PVC mit dem Namen PVC_NAME bereits bereitgestellt wurde. SOURCE_USER_CLUSTER_NAME ist der Name des Quellclusters, in dem die PVC vorhanden ist, und DESTINATION_USER_CLUSTER_NAME ist der Name des Zielclusters, in dem eine neue PVC vorhanden sein wird.

Die Felder source und destination der Spezifikation geben an, von und bis wohin die Daten repliziert werden. In diesem Beispiel werden die Daten von SOURCE_ZONE_NAME nach DESTINATION_ZONE_NAME 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.

VM Disk API

VM-Laufwerke replizieren

VolumeReplicationRelationship stellt auch die API für die asynchrone Replikation von VM-Laufwerken bereit. 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“. Prüfen Sie, ob Sie die Rolle „Project VirtualMachine Admin“ (project-vm-admin) im Namespace des Projekts haben, in dem sich das VM-Laufwerk befindet.

Für VM-Vorgänge mit der gcloud CLI bitten Sie Ihren Projekt-IAM-Administrator, 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 ein VirtualMachineDisk mit dem Namen VIRTUAL_MACHINE_SOURCE_DISK_NAME bereits für die VirtualMachine-Ressource bereitgestellt wurde.

Die Felder source und destination der Spezifikation geben an, von und bis 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 ein VirtualMachineDisk in der Zielzone, in das die replizierten Daten geschrieben werden. 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 aus der globalen API abrufen. Sehen Sie sich das folgende Beispiel an. 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

Falls die Quellzone aus irgendeinem Grund nicht verfügbar ist, kann ein VolumeFailover CR in der Verwaltungsebene der Zielzone der Organisation erstellt werden. Bei einer Organisation der Version 2 wäre das der Management API-Server. In einer v1-Organisation ist dies der Administratorcluster der Organisation. Wenn beispielsweise ein VolumeReplicationRelationship erstellt wurde, in dem zone2 als Zielzone angegeben ist, und ein PVC oder VirtualMachineDisk in der Organisation my-org vorhanden ist, wird die benutzerdefinierte Ressource VolumeFailover in der Steuerungsebene my-org in zone2 erstellt. Dadurch wird die Replikationsbeziehung zwischen den beiden Zonen unterbrochen und der PVC oder 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.

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

  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 my-vrr-repl VolumeReplicationRelationship in den Status Broken Off. Das PVC oder die VirtualMachineDisk in zone2 kann jetzt eingebunden werden.

• An dieser Stelle sieht VolumeReplicationRelationship etwa so 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

• Sie können nun die VolumeReplicationRelationship löschen, da dies die einzige verbleibende Aktion ist, die für diese CR ausgeführt werden kann.

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

Größe von Volumes ändern

Wenn die Größe des Quellvolumes zu einem beliebigen Zeitpunkt geändert wird, sollte auch die Größe des entsprechenden Volumes in der Zielzone, das im Namen des Nutzers beim Erstellen eines VolumeReplicationRelationship erstellt wird, entsprechend geändert werden.

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