Volumes asynchron replizieren

Auf dieser Seite wird beschrieben, wie Sie die asynchrone Replikation von Google Distributed Cloud-Block-Storage-Volumes (GDC) einrichten und ausführen, die nicht mit dem Internet verbunden sind.

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. Hinweis: Sobald ein Failover erstellt wurde, kann das ursprüngliche Volume nicht auf dasselbe Zielvolume repliziert werden. Stattdessen muss eine neue Replikationsbeziehung erstellt werden.

Hinweise

Damit die asynchrone Blockreplizierung zwischen zwei Zonen möglich ist, muss Ihr Infrastrukturbetreiber (IO) zuerst die erforderliche Speicherinfrastruktur einrichten, indem er die relevanten Speichercluster aus jeder Zone per Peering verbindet. Als Nächstes muss die Storage-VM, die der Organisation zugeordnet ist, in der der Blockspeicher bereitgestellt wird, per Peering verbunden werden.

Prüfen Sie anschließend, 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 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:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
 destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2

In diesem Beispiel wird davon ausgegangen, dass ein Projekt mit dem Namen my-project in einer Organisation mit dem Namen my-org erstellt wurde und dass ein PVC mit dem Namen my-block-pvc bereits bereitgestellt wurde. clusterRef ist der Name des Clusters, in dem der PVC vorhanden ist.

Die Felder source und destination der Spezifikation geben an, von und nach wo die Daten repliziert werden. In diesem Beispiel werden die Daten von xx-xxxx-zone1 nach xx-xxxx-zone2 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.

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:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-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: xx-xxxx-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 Zielzone der Organisation ein VolumeFailover-CR erstellt werden. Bei einer Organisation der Version 2 ist das der Management API-Server. In einer v1-Organisation ist dies der Administratorcluster der Organisation. Wenn beispielsweise ein VolumeReplicationRelationship erstellt wurde, in dem xx-xxxx-zone2 als Zielzone angegeben ist, und ein PVC in der Organisation my-org vorhanden ist, wird das CR VolumeFailover in der Verwaltungsebene my-org in xx-xxxx-zone2 erstellt. Dadurch wird die Replikationsbeziehung zwischen den beiden Zonen unterbrochen und der PVC in der Zielzone kann von einer Arbeitslast bereitgestellt werden:

apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: my-pvc-failover
  namespace: my-project
spec:
  volumeReplicationRelationshipRef: my-pvc-repl

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

apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: my-pvc-failover
  namespace: my-project
spec:
  volumeReplicationRelationshipRef: my-pvc-repl
status:
    state: Completed

Nachdem das Failover erstellt wurde, wechselt my-pvc-repl VolumeReplicationRelationship in den Status Broken Off. Das PVC in xx-xxxx-zone2 kann jetzt gemountet werden.

An dieser Stelle sollte VolumeReplicationRelationship in etwa so aussehen: Die Ausgabe wurde der Einfachheit halber gekürzt:

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: xx-xxxx-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 sicher löschen, da dies die einzige verbleibende Aktion ist, die für diese benutzerdefinierte Ressource ausgeführt werden kann.

Größe von Volumes ändern

Wenn das Quell-Volume zu einem beliebigen Zeitpunkt in der Größe geändert wird, sollte das entsprechende Volume in der Zielzone, das im Namen des Nutzers erstellt wird, wenn eine VolumeReplicationRelationship erstellt wird, ebenfalls in der Größe geändert werden.

VM-Laufwerke replizieren

VolumeReplicationRelationship unterstützt auch die asynchrone API zur 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 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

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

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.

API

kubectl --kubeconfig GLOBAL_MANAGEMENT_API \
  apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: PRIMARY_DISK_NAME
    zoneRef: PRIMARY_ZONE
  destination:
    volumeOverrideName: SECONDARY_DISK_NAME
    zoneRef: SECONDARY_ZONE
EOF

Ersetzen Sie Folgendes:

Variable	Definition
GLOBAL_MANAGEMENT_API	Die kubeconfig-Datei für den globalen Management-API-Server.
VRR_NAME	Der Name der Volume-Replikationsbeziehung. Beim Beenden der asynchronen Replikation muss derselbe Name verwendet werden.
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.
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.

Asynchrone Replikationsbeziehungen auflisten

Asynchrone Replikationsbeziehungen in einem Projekt mit kubectl auflisten.

kubectl --kubeconfig GLOBAL_MANAGEMENT_API get volumereplicationrelationships -n my-project

Ersetzen Sie Folgendes:

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

Die Ausgabe sieht 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 Beziehungen zur Volumereplikation, die dem primären VM-Laufwerk entsprechen.

   kubectl --kubeconfig GLOBAL_MANAGEMENT_API 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 Beziehungen zur Volumereplikation.

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

   Ersetzen Sie Folgendes:

   Variable	Definition
   GLOBAL_MANAGEMENT_API	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.