Volumes asynchron replizieren

Auf dieser Seite wird beschrieben, wie Sie die asynchrone Replikation von GDC-Blockspeicher-Volumes (Google Distributed Cloud) mit Air Gap 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 ein Failover verwendet werden, wenn die Daten der Quellzone nicht mehr verfügbar sind. Nachdem ein Failover erstellt wurde, kann das ursprüngliche Volume nicht mehr auf dasselbe Zielvolume repliziert werden. Stattdessen muss eine neue Replikationsbeziehung erstellt werden.

Informationen für Plattformadministratoren, die PVCs mit der KRM API verwalten, finden Sie unter Volumes asynchron replizieren (für Plattformadministratoren).

Hinweis

Wenn Sie die asynchrone Blockreplikation verwenden möchten, muss Ihr Infrastruktur-Operator (IO) zuerst zwei Zonen für die asynchrone Replikation einrichten.

Prüfen Sie dann, ob Sie die Rolle app-volume-replication-admin-global zum Verwalten der VolumeReplicationRelationship-Ressource haben. Wenn die globale API nicht verfügbar ist, kann die Rolle 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. Wenn Sie die Replikation für ein bestimmtes blockorientiertes Gerät aktivieren möchten, muss in der globalen Verwaltungs-API eine VolumeReplicationRelationship-CR erstellt werden:

PVC API replizieren

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

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 Laufwerken virtueller Maschinen 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.

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 Quelllaufwerks, das repliziert wird.
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 Disk API

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.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: der Name der VirtualMachineDisk-Ressource am Ziel.
• DESTINATION_ZONE_NAME: der Name der Zielzonenressource.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: der Name der VirtualMachineDisk-Ressource in der Quelle.
• SOURCE_ZONE_NAME: der Name der Quellzonenressource.

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. Sie können jedoch das Feld volumeOverrideName verwenden, um den Namen der erstellten VirtualMachineDisk anzugeben. 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 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 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

• Sie können die VolumeReplicationRelationship jetzt sicher löschen, 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 geändert wird, müssen Sie auch die Größe des entsprechenden Volumes in der Zielzone anpassen. Das Volume in der Zielzone wird erstellt, wenn Sie die VolumeReplicationRelationship erstellen.

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

Asynchrone Replikationsbeziehungen auflisten

Asynchrone Replikationsbeziehungen in einem Projekt mit kubectl auflisten.

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 Verwaltungs-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 Quelllaufwerks, das repliziert wird.
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 alle 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 Verwaltungs-API-Server.
   PROJECT	Das GDC-Projekt des primären Laufwerks.
   PRIMARY_DISK_NAME	Der Name des Quelllaufwerks, das repliziert wird.
   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.