Replica asincrona dei volumi

Questa pagina descrive come configurare ed eseguire la replica asincrona dei volumi di archiviazione a blocchi con air gap di Google Distributed Cloud (GDC).

La replica asincrona viene utilizzata per replicare i dati da una zona GDC a un'altra. I dati replicati possono essere utilizzati per il failover se i dati della zona di origine non sono disponibili. Tieni presente che, una volta creato un failover, non è possibile replicare il volume originale nello stesso volume di destinazione. È invece necessario creare una nuova relazione di replica.

Per gli amministratori della piattaforma che gestiscono i PVC utilizzando l'API KRM, consulta Replica i volumi in modo asincrono per gli amministratori della piattaforma.

Prima di iniziare

Per utilizzare la replica asincrona dei blocchi, l'operatore dell'infrastruttura (IO) deve prima configurare due zone per la replica asincrona.

Poi, assicurati di disporre del ruolo app-volume-replication-admin-global per amministrare la risorsa VolumeReplicationRelationship. Nei casi in cui l'API globale non è disponibile, il ruolo volume-replication-admin può essere utilizzato per modificare direttamente la risorsa VolumeReplicationRelationshipReplica a livello di zona.

Configura la replica

La risorsa personalizzata (CR) VolumeReplicationRelationship gestisce l'API di replica asincrona dei blocchi. Questa CR esiste nell'API di gestione globale. Per abilitare la replica per un determinato dispositivo a blocchi, è necessario creare una CR VolumeReplicationRelationship nell'API di gestione globale:

API Replicate PVC

Nota: è richiesta l'associazione del progetto. Assicurati di aver collegato il tuo progetto a ogni risorsa Cluster in ogni zona partecipante.

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

Sostituisci quanto segue:

• MANAGEMENT_API_SERVER: il percorso kubeconfig del server API di zona.
• VRR_NAME: il nome della risorsa VolumeReplicationRelationship.
• PROJECT: lo spazio dei nomi della risorsa Project.
• SOURCE_USER_CLUSTER_NAME: il nome della risorsa Cluster utente di origine da connettere.
• PVC_NAME: il nome della risorsa PersistentVolumeClaim.
• SOURCE_ZONE_NAME: il nome della risorsa di zona di origine.
• DESTINATION_USER_CLUSTER_NAME: il nome della risorsa del cluster utente di destinazione da connettere.
• DESTINATION_ZONE_NAME: il nome della risorsa di zona di destinazione.

Questo esempio presuppone che un progetto denominato PROJECT sia stato creato in un'organizzazione denominata my-org e che sia già stato eseguito il provisioning di una PVC denominata PVC_NAME. SOURCE_USER_CLUSTER_NAME è il nome del cluster di origine in cui esiste il PVC e DESTINATION_USER_CLUSTER_NAME è il nome del cluster di destinazione in cui esisterà un nuovo PVC.

I campi source e destination della specifica indicano rispettivamente da dove e verso dove vengono replicati i dati. In questo esempio, i dati vengono replicati da SOURCE_ZONE_NAME a DESTINATION_ZONE_NAME.

Nota: il servizio di replica asincrona dei blocchi crea automaticamente un PVC nella zona di destinazione per la scrittura dei dati replicati. Per impostazione predefinita, questo PVC ha lo stesso nome del PVC di origine, ma puoi utilizzare il campo volumeOverrideName per specificare il nome del PVC creato. Tuttavia, finché non viene creato un VolumeReplicationFailover, la PVC di destinazione rimane di sola lettura e non può essere montata da nessun workload.

Replica i dischi delle macchine virtuali

VolumeReplicationRelationship gestisce anche l'API di replica asincrona dei dischi delle macchine virtuali (dischi VM). Il disco di origine replicato è chiamato disco primario. Il disco di destinazione su cui viene eseguita la replica è chiamato disco secondario. L'avvio della replica asincrona su un disco primario crea automaticamente il disco secondario.

Richiedi autorizzazioni e accesso

Per replicare i dischi delle macchine virtuali, devi disporre del ruolo Project VirtualMachine Admin. Segui i passaggi per verificare di disporre del ruolo Project VirtualMachine Admin (project-vm-admin) nello spazio dei nomi del progetto in cui si trova il disco della VM.

Per le operazioni sulle macchine virtuali utilizzando la CLI gdcloud, chiedi all'amministratore del progetto IAM di assegnarti sia il ruolo Project VirtualMachine Admin sia il ruolo Project Viewer (project-viewer).

gdcloud

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

Sostituisci quanto segue:

Variabile	Definizione
PRIMARY_DISK_NAME	Il nome del disco di origine da replicare.
PROJECT	Il progetto GDC del disco primario.
PRIMARY_ZONE	La zona in cui si trova il disco primario.
SECONDARY_DISK_NAME	Il nome del disco di destinazione in cui eseguire la replica.
SECONDARY_ZONE	La zona in cui deve risiedere il disco secondario.

API VM Disk

Avvia la replica asincrona

Avvia la replica asincrona su un disco VM utilizzando 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

Sostituisci quanto segue:

• MANAGEMENT_API_SERVER: il percorso kubeconfig del server API di zona.
• VRR_NAME: il nome della risorsa VolumeReplicationRelationship.
• PROJECT: lo spazio dei nomi della risorsa Project.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: il nome della risorsa VirtualMachineDisk nella destinazione.
• DESTINATION_ZONE_NAME: il nome della risorsa di zona di destinazione.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: il nome della risorsa VirtualMachineDisk nell'origine.
• SOURCE_ZONE_NAME: il nome della risorsa di zona di origine.

Questo esempio presuppone che un progetto denominato PROJECT sia stato creato in un'organizzazione denominata my-org e che sia già stato eseguito il provisioning di un VirtualMachineDisk denominato VIRTUAL_MACHINE_SOURCE_DISK_NAME nella risorsa VirtualMachine.

I campi source e destination della specifica indicano rispettivamente da dove e verso dove vengono replicati i dati. In questo esempio, i dati vengono replicati da SOURCE_ZONE_NAME a DESTINATION_ZONE_NAME.

Nota: il servizio di replica asincrona dei blocchi crea automaticamente un VirtualMachineDisk nella zona di destinazione per la scrittura dei dati replicati. Per impostazione predefinita, questo VirtualMachineDisk ha lo stesso nome del VirtualMachineDisk di origine; tuttavia, puoi utilizzare il campo volumeOverrideName per specificare il nome del VirtualMachineDisk creato. Tuttavia, finché non viene creato un VolumeReplicationFailover, il VirtualMachineDisk di destinazione rimane di sola lettura e non può essere montato da nessun workload.

Verifica

Controlla lo stato della relazione di replica recuperando la CR VolumeReplicationRelationship dall'API globale. Fai riferimento all'esempio seguente. Tieni presente che l'output è stato troncato per semplicità:

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
        -n PROJECT -o yaml

L'output è simile al seguente:

API PVC

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

API VM Disk

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

Crea failover

Se la zona di origine non è disponibile per qualsiasi motivo, è possibile creare una CR VolumeFailover nel piano di gestione dell'organizzazione della zona di destinazione. Per un'organizzazione v2, si tratta del server API di gestione. Per un'organizzazione v1, si tratta del cluster di amministrazione dell'organizzazione. Ad esempio, se è stata creata una VolumeReplicationRelationship che specifica zone2 come zona di destinazione ed esiste un PVC o un VirtualMachineDisk nell'organizzazione my-org, la CR VolumeFailover viene creata nel piano di gestione my-org in zone2. In questo modo, la relazione di replica tra le due zone viene interrotta e un workload può montare il PVC o VirtualMachineDisk nella zona di destinazione:

  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

Sostituisci quanto segue:

• FAILOVER_NAME: il nome della risorsa VolumeFailover.
• MANAGEMENT_API_SERVER: il percorso kubeconfig del server API di zona.
• VRR_NAME: il nome della risorsa VolumeReplicationRelationship.
• PROJECT: lo spazio dei nomi della risorsa Project.

In seguito, un failover riuscito si riflette nello stato della CR:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumefailover FAILOVER_NAME \
          -n PROJECT -o yaml

• L'output è simile al seguente:

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

• Dopo aver creato il failover, my-vrr-repl VolumeReplicationRelationship passa allo stato Broken Off. Il PVC o il VirtualMachineDisk in zone2 è ora montabile.

• A questo punto, il VolumeReplicationRelationship sarà simile all'esempio seguente. Anche in questo caso, l'output è stato troncato per semplificazione:

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
          -n PROJECT -o yaml
  

• L'output è simile al seguente:

API PVC

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

API VM Disk

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

• Ora puoi eliminare in sicurezza VolumeReplicationRelationship perché è l'unica azione rimanente che può essere eseguita su questa RC.

  kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationship VRR_NAME \
          -n PROJECT
  

Ridimensiona i volumi

Se in qualsiasi momento il volume di origine viene ridimensionato, devi ridimensionare anche il volume corrispondente nella zona di destinazione in modo che corrisponda. Il volume della zona di destinazione viene creato quando crei VolumeReplicationRelationship.

Consulta la documentazione Espandi i dischi delle VM o Espandi la capacità del volume per ridimensionare lo spazio di archiviazione sia nelle zone di origine che in quelle di destinazione.

Elenca le relazioni di replica asincrona

Elenca le relazioni di replica asincrona in un progetto utilizzando kubectl.

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

Sostituisci quanto segue:

• PROJECT: il progetto GDC del disco primario.
• MANAGEMENT_API_SERVER: il file kubeconfig per il server API di gestione a livello di zona.

L'output è simile al seguente:

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

Interrompi la replica asincrona

Arresta la replica asincrona su un disco VM principale utilizzando gdcloud o kubectl.

gdcloud

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

Sostituisci quanto segue:

Variabile	Definizione
PRIMARY_DISK_NAME	Il nome del disco di origine da replicare.
PROJECT	Il progetto GDC del disco primario.
PRIMARY_ZONE	La zona in cui si trova il disco primario.

API

1. Trova le relazioni di replica dei volumi corrispondenti al disco della VM principale.

   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. Elimina ciascuna delle relazioni di replica dei volumi elencate nel passaggio precedente. Sostituisci VRR_NAMES con i nomi delle relazioni di replica del volume.

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

   Sostituisci quanto segue:

   Variabile	Definizione
   MANAGEMENT_API_SERVER	Il file kubeconfig per il server API di gestione globale.
   PROJECT	Il progetto GDC del disco primario.
   PRIMARY_DISK_NAME	Il nome del disco di origine da replicare.
   PRIMARY_ZONE	La zona in cui si trova il disco primario.

Se la zona di origine non è disponibile per qualsiasi motivo, crea un failover del volume per interrompere la replica.

Collega il disco replicato a una VM

Mentre la replica è abilitata, il disco secondario non può essere collegato a una VM. Una volta interrotta la replica, puoi collegare il disco secondario a una VM appena creata o a una VM esistente.