Volumes asynchron replizieren

Auf dieser Seite erfahren Sie, wie Sie die asynchrone Replikation von Google Distributed Cloud (GDC) Air-Gapped-Blockspeicher-Volumes 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. Sobald 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.

Anwendungsoperatoren, die die gdcloud CLI verwenden möchten, finden weitere Informationen unter Volumes asynchron replizieren.

Hinweis

Damit die asynchrone Blockreplikation verwendet werden kann, muss Ihr Infrastrukturadministrator zuerst zwei Zonen für die asynchrone Replikation einrichten.

Prüfen Sie, 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 Ressource VolumeReplicationRelationshipReplica direkt zu ändern.

Replikation einrichten

Die benutzerdefinierte Ressource (Custom Resource, 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 Blockgerät aktiviert werden kann, muss eine VolumeReplicationRelationship-CR in der globalen Management API erstellt werden:

PVC API

Die Projektbindung ist erforderlich. Achten Sie darauf, dass Sie Ihr Projekt in jeder beteiligten Zone an jede Clusterressource 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 Ressource VolumeReplicationRelationship.
• PROJECT: der Namespace der Ressource Project.
• SOURCE_USER_CLUSTER_NAME: der Name der zu verbindenden Quell-Nutzerclusterressource.
• PVC_NAME: der Name der Ressource PersistentVolumeClaim.
• SOURCE_ZONE_NAME: der Name der Quellzonenressource.
• DESTINATION_USER_CLUSTER_NAME: der Name der zu verbindenden Ziel-Nutzerclusterressource.
• 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. Der SOURCE_USER_CLUSTER_NAME ist der Name des Quellclusters, in dem der PVC vorhanden ist, und der DESTINATION_USER_CLUSTER_NAME ist der Name des Zielclusters, in dem ein neuer PVC vorhanden sein wird.

Die Felder source und destination der Spezifikation geben an, von wo bzw. 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 stellt auch die API für die asynchrone Replikation von VM-Laufwerken bereit. Das zu replizierende Quelllaufwerk 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.

Für VM-Vorgänge mit der gdcloud 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

Starten Sie die asynchrone Replikation auf einem VM-Laufwerk mit kubectl.

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 Ressource VolumeReplicationRelationship.
• PROJECT: der Namespace der Ressource Project.
• SOURCE_ZONE_NAME: der Name der Quellzonenressource.
• DESTINATION_ZONE_NAME: der Name der Zielzonenressource.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: der Name der Ressource VirtualMachineDisk in der Quelle.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: der Name der Ressource VirtualMachineDisk im 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 eine VirtualMachineDisk mit dem Namen VIRTUAL_MACHINE_SOURCE_DISK_NAME bereits für die Ressource VirtualMachine bereitgestellt wurde.

Die Felder source und destination der Spezifikation geben an, von wo bzw. 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 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 die 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. Beachten Sie das folgende 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 eine VolumeFailover-CR in der Managementebene der Organisation der Zielzone erstellt werden. Bei einer v2-Organisation ist dies der Management-API-Server. Bei einer v1-Organisation ist dies der Administratorcluster der Organisation. Wenn beispielsweise eine VolumeReplicationRelationship erstellt wurde, in der zone2 als Zielzone angegeben ist, und ein PVC oder eine VirtualMachineDisk in der Organisation my-org vorhanden ist, wird die VolumeFailover-CR in der Managementebene 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 Ressource VolumeFailover.
• MANAGEMENT_API_SERVER: der kubeconfig-Pfad des zonalen API-Servers.
• VRR_NAME: der Name der Ressource VolumeReplicationRelationship.

• PROJECT: der Namespace der Ressource Project.

• Nach einem erfolgreichen Failover wird dies im Status der CR 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 diesem Punkt sieht die VolumeReplicationRelationship ähnlich wie im folgenden 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 können Sie die VolumeReplicationRelationship gefahrlos 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 Quell-Volumes geändert wird, sollte auch die Größe des entsprechenden Volumes in der Zielzone angepasst werden. Dieses wird im Namen des Nutzers erstellt, wenn eine VolumeReplicationRelationship erstellt wird.

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