Volumes asynchron replizieren

Auf dieser Seite wird beschrieben, wie Sie die asynchrone Replikation von Blockspeicher-Volumes mit Air Gap in Google Distributed Cloud (GDC) einrichten und ausführen.

Die asynchrone Replikation wird verwendet, um Daten von einer GDC-Zone in eine andere zu replizieren. Die replizierten Daten können für das Failover verwendet werden, wenn die Daten der Quellzone nicht mehr verfügbar sind. Beachten Sie, dass ein Failover, sobald es erstellt wurde, nicht mehr in dasselbe Ziel-Volume repliziert werden kann. Stattdessen muss eine neue Replikationsbeziehung erstellt werden.

Hinweis

Damit die asynchrone Blockreplikation verwendet werden kann, muss der Infrastrukturbetreiber zuerst die Speicherinfrastruktur zwischen den beiden Zonen einrichten, in denen die Replikation erforderlich ist. Dazu muss er zuerst die relevanten Speichercluster aus jeder Zone peeren. Als Nächstes muss er die virtuelle Speicher-VM peeren, die mit der Organisation verknüpft ist, in der der Blockspeicher bereitgestellt wird.

Prüfen Sie dann, ob Sie die Rolle app-volume-replication-admin-global haben, um die Ressource VolumeReplicationRelationship zu verwalten. Wenn die globale API nicht verfügbar ist, kann die Rolle 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. Um die Replikation für ein bestimmtes Blockgerät zu aktivieren, muss in der globalen Management API eine VolumeReplicationRelationship-CR erstellt werden:

PVC-API replizieren

**Hinweis**: Eine Projektbindung ist erforderlich. Achten Sie darauf, dass Sie Ihr Projekt in jeder beteiligten Zone an jede Cluster-Ressource 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 Quell-Cluster-Ressource, die verbunden werden soll.
• PVC_NAME: der Name der Ressource PersistentVolumeClaim.
• SOURCE_ZONE_NAME: der Name der Quellzonen-Ressource.
• DESTINATION_USER_CLUSTER_NAME: der Name der Ziel-Cluster-Ressource, die verbunden werden soll.
• DESTINATION_ZONE_NAME: der Name der Zielzonen-Ressource.

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. Sie können jedoch mit dem Feld volumeOverrideName den Namen des erstellten PVC angeben. Bis ein VolumeReplicationFailover erstellt wird, bleibt der Ziel-PVC jedoch schreibgeschützt und kann von keinen Arbeitslasten bereitgestellt werden.

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 automatisch das sekundäre Laufwerk erstellt.

Berechtigungen und Zugriff anfordern

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

Für Vorgänge mit virtuellen Maschinen über die gdcloud CLI bitten Sie Ihren Projekt-IAM-Administrator, Ihnen sowohl die Rolle „Project VirtualMachine Admin“ als auch die Rolle „Project Viewer“ (project-viewer) zuzuweisen.

gdcloud

gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
  --project PROJECT --zone PRIMARY_ZONE \
  --secondary-disk SECONDARY_DISK_NAME --secondary-zone SECONDARY_ZONE

Ersetzen Sie Folgendes:

Variable	Definition
PRIMARY_DISK_NAME	Der Name des zu replizierenden Quelllaufwerks.
PROJECT	Das GDC-Projekt des primären Laufwerks.
PRIMARY_ZONE	Die Zone, in der sich das primäre Laufwerk befindet.
SECONDARY_DISK_NAME	Der Name des Ziellaufwerks, auf das repliziert werden soll.
SECONDARY_ZONE	Die Zone, in der sich das sekundäre Laufwerk befinden muss.

VM-Laufwerk-API

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.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: der Name der Ressource VirtualMachineDisk am Ziel.
• DESTINATION_ZONE_NAME: der Name der Zielzonen-Ressource.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: der Name der Ressource VirtualMachineDisk an der Quelle.
• SOURCE_ZONE_NAME: der Name der Quellzonen-Ressource.

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. Sie können jedoch mit dem Feld volumeOverrideName den Namen der erstellten VirtualMachineDisk angeben. 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. 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-Laufwerk-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 Managementebene 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 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 eine Arbeitslast kann den PVC oder die VirtualMachineDisk in der Zielzone bereitstellen:

  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 etwa so aus wie im folgenden Beispiel. 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-Laufwerk-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 die VolumeReplicationRelationship jetzt 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, müssen Sie auch die Größe des entsprechenden Volumes in der Zielzone anpassen. Das Volume der Zielzone wird erstellt, wenn Sie die VolumeReplicationRelationship erstellen.

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

Asynchrone Replikationsbeziehungen auflisten

Listen Sie asynchrone Replikationsbeziehungen in einem Projekt mit kubectl auf.

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

Ersetzen Sie Folgendes:

• PROJECT: Das GDC-Projekt des primären Laufwerks.
• MANAGEMENT_API_SERVER: Die kubeconfig-Datei für den zonalen Management API-Server.

Die Ausgabe sieht dann ungefähr so aus:

NAME       AGE     SOURCE ZONE   SOURCE PVC   SOURCE PVC CLUSTER   SOURCE VM DISK      DEST. ZONE   DEST. PVC CLUSTER   DEST. VOLUME OVERRIDE     STATE
my-vrr     3m21s   zone1                                           my-vm-boot-disk     zone2                            my-vm-boot-disk-replica
test-vrr   7s      zone1                                           test-vm-boot-disk   zone2

Asynchrone Replikation beenden

Beenden Sie die asynchrone Replikation auf einem primären VM-Laufwerk mit gdcloud oder kubectl.

gdcloud

gdcloud compute disks stop-async-replication PRIMARY_DISK_NAME \
  --project PROJECT --zone PRIMARY_ZONE

Ersetzen Sie Folgendes:

Variable	Definition
PRIMARY_DISK_NAME	Der Name des zu replizierenden Quelllaufwerks.
PROJECT	Das GDC-Projekt des primären Laufwerks.
PRIMARY_ZONE	Die Zone, in der sich das primäre Laufwerk befindet.

API

1. Suchen Sie die Volume-Replikationsbeziehungen, die dem primären VM-Laufwerk entsprechen.

   kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships \
     -n PROJECT -o json | \
     jq -r '.items[] | select(.spec.source.virtualMachineDisk.virtualMachineDiskRef == "PRIMARY_DISK_NAME"
     and .spec.source.zoneRef == "PRIMARY_ZONE") | .metadata.name'
   

2. Löschen Sie jede der im vorherigen Schritt aufgeführten Volume-Replikationsbeziehungen. Ersetzen Sie VRR_NAMES durch die Namen der Volume-Replikationsbeziehungen.

   kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationships \
     -n PROJECT VRR_NAMES
   

   Ersetzen Sie Folgendes:

   Variable	Definition
   MANAGEMENT_API_SERVER	Die kubeconfig-Datei für den globalen Management API-Server.
   PROJECT	Das GDC-Projekt des primären Laufwerks.
   PRIMARY_DISK_NAME	Der Name des zu replizierenden Quelllaufwerks.
   PRIMARY_ZONE	Die Zone, in der sich das primäre Laufwerk befindet.

Wenn die Quellzone aus irgendeinem Grund nicht verfügbar ist, erstellen Sie ein Volume-Failover, um die Replikation zu beenden.

Repliziertes Laufwerk an eine VM anhängen

Wenn die Replikation aktiviert ist, kann das sekundäre Laufwerk nicht an eine VM angehängt werden. Nachdem die Replikation beendet wurde, können Sie das sekundäre Laufwerk an eine neu erstellte VM oder an eine vorhandene VM anhängen.