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 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 Ziel-Volume 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.

Hinweis

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

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 „VolumeReplicationRelationship“ (Custom Resource, CR) stellt die asynchrone Blockreplikations-API bereit. Diese CR ist in der globalen Management API vorhanden. Wenn Sie die Replikation für ein bestimmtes Blockgerät aktivieren möchten, muss eine VolumeReplicationRelationship CR in der globalen Management API erstellt werden:

PVC API replizieren

**Hinweis**: Eine Projektbindung ist erforderlich. Achten Sie darauf, dass Sie Ihr Projekt mit jeder Cluster-Ressource in jeder beteiligten Zone verknüpft 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 Quellcluster-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 Zielcluster-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. `SOURCE_USER_CLUSTER_NAME` ist der Name des Quellclusters, in dem sich der PVC befindet, und `DESTINATION_USER_CLUSTER_NAME` ist der Name des Zielclusters, in dem ein neuer PVC erstellt 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 asynchrone Blockreplikationsdienst 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 asynchrone Replikations-API für VM-Laufwerke 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 automatisch das sekundäre Laufwerk 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“ haben (project-vm-admin) im Namespace des Projekts, 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.

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-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 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 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 eine VolumeFailover CR in der Verwaltungsebene der Organisation der Zielzone 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 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 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“.

Ein erfolgreiches Failover wird 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-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 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 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 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.