Replica asincrona dei volumi

Questa pagina descrive come configurare ed eseguire la replica asincrona dei volumi di archiviazione a blocchi isolati da internet 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 più disponibili. Tieni presente che, una volta creato un failover, il volume originale non può essere replicato nello stesso volume di destinazione. È necessario creare una nuova relazione di replica.

Prima di iniziare

Per abilitare la replica asincrona dei blocchi tra due zone, l'operatore dell'infrastruttura (IO) deve prima stabilire l'infrastruttura di archiviazione necessaria eseguendo il peering dei cluster di archiviazione pertinenti di ogni zona. Successivamente, deve eseguire il peering della macchina virtuale di archiviazione associata all'organizzazione in cui viene eseguito il provisioning dell'archiviazione a blocchi.

Successivamente, assicurati di disporre del ruolo app-volume-replication-admin-global per amministrare la risorsa VolumeReplicationRelationship. Se l'API globale non è disponibile, il ruolo volume-replication-admin può essere utilizzato per modificare direttamente la risorsa VolumeReplicationRelationshipReplica zonale.

Configurare la replica

La risorsa personalizzata (CR) VolumeReplicationRelationship gestisce l'API di replica asincrona dei blocchi. Questa risposta predefinita 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:

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

Questo esempio presuppone che un progetto denominato my-project venga creato in un'organizzazione denominata my-org e che sia già stato eseguito il provisioning di un PVC denominato my-block-pvc. clusterRef è il nome del cluster su cui esiste il PVC.

I campi source e destination della specifica indicano rispettivamente la posizione di origine e di destinazione della replica dei dati. In questo esempio, i dati vengono replicati da xx-xxxx-zone1 a xx-xxxx-zone2.

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, tuttavia, il campo VolumeOverrideName può essere utilizzato per specificare il nome del PVC creato. Finché non viene creato un VolumeReplicationFailover, tuttavia, il PVC di destinazione rimane di sola lettura e non può essere montato da alcun workload.

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 semplificare la visualizzazione:

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

Crea failover

Se la zona di origine non è disponibile per qualsiasi motivo, è possibile creare un VolumeFailover CR nel piano di gestione dell'organizzazione della zona di destinazione. Per un'organizzazione v2, questo sarebbe il server API di gestione. Per un'organizzazione v1, questo sarebbe il cluster di amministrazione dell'organizzazione. Ad esempio, se è stato creato un VolumeReplicationRelationship che specifica xx-xxxx-zone2 come zona di destinazione e la PVC esiste nell'organizzazione my-org, la CR VolumeFailover viene creata nel piano di gestione my-org in xx-xxxx-zone2. In questo modo, la relazione di replica tra le due zone viene interrotta e il PVC nella zona di destinazione può essere montato da un workload:

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

Successivamente, un failover riuscito viene visualizzato nello stato della CR:

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

Dopo la creazione del failover, my-pvc-repl VolumeReplicationRelationship passa allo stato Broken Off. Il PVC in xx-xxxx-zone2 ora può essere montato.

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

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

Ora puoi eliminare VolumeReplicationRelationship in quanto è l'unica azione rimanente che può essere eseguita su questo CR.

Ridimensionare i volumi

Se in un determinato momento viene ridimensionato il volume di origine, anche il volume corrispondente nella zona di destinazione, creato per conto dell'utente quando viene creata una VolumeReplicatioRelationship, deve essere ridimensionato in modo che corrisponda.

Replica i dischi delle macchine virtuali

VolumeReplicationRelationship gestisce anche l'API di replica asincrona del disco della macchina virtuale (disco 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 creerà automaticamente il disco secondario.

Richiedere autorizzazioni e accesso

Per replicare i dischi VM, devi disporre del ruolo Amministratore macchina virtuale progetto. Segui i passaggi per verificare di disporre del ruolo Amministratore macchina virtuale progetto (project-vm-admin) nello spazio dei nomi del progetto in cui si trova il disco della VM.

Per le operazioni sulle VM che utilizzano gcloud CLI, chiedi all'amministratore IAM del progetto di assegnarti il ruolo Amministratore di macchine virtuali del progetto e il ruolo Visualizzatore progetto (project-viewer).

Avvia la replica asincrona

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

Sostituisci quanto segue:

Variabile	Definizione
PRIMARY_DISK_NAME	Il nome del disco di origine in fase di replica.
PROJECT	Il progetto GDC del disco primario.
PRIMARY_ZONE	La zona in cui si trova il disco principale.
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

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

Sostituisci quanto segue:

Variabile	Definizione
GLOBAL_MANAGEMENT_API	Il file kubeconfig per il server API di gestione globale.
VRR_NAME	Il nome della relazione di replica del volume. Quando arresti la replica asincrona, devi utilizzare lo stesso nome.
PROJECT	Il progetto GDC del disco primario.
PRIMARY_DISK_NAME	Il nome del disco di origine in fase di replica.
PRIMARY_ZONE	La zona in cui si trova il disco principale.
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.

Elenca le relazioni di replica asincrona

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

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

Sostituisci quanto segue:

• PROJECT: Il progetto GDC del disco primario.
• GLOBAL_MANAGEMENT_API: il file kubeconfig per il server API di gestione globale.

L'output sarà 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 primario utilizzando gcloud 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 in fase di replica.
PROJECT	Il progetto GDC del disco primario.
PRIMARY_ZONE	La zona in cui si trova il disco principale.

API

1. Trova le relazioni di replica del volume corrispondenti al disco della VM primaria.

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

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

   Sostituisci quanto segue:

   Variabile	Definizione
   GLOBAL_MANAGEMENT_API	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 in fase di replica.
   PRIMARY_ZONE	La zona in cui si trova il disco principale.

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.