Replica asincrona dei volumi

Questa pagina mostra come configurare ed eseguire la replica asincrona dei volumi di archiviazione a blocchi air-gapped di Google Distributed Cloud (GDC).

La replica asincrona viene utilizzata per replicare i dati da una zona GDC a un'altra. Questi dati replicati possono essere utilizzati in uno scenario di failover nel caso in cui i dati nella zona di origine non siano disponibili. Tieni presente che, una volta creato un failover, non è possibile configurare il volume originale per la replica nello stesso volume di destinazione. Al contrario, è necessario creare una nuova relazione di replica.

Prima di iniziare

Per utilizzare la replica asincrona dei blocchi, l'operatore dell'infrastruttura (IO) deve prima configurare l'infrastruttura di archiviazione tra le due zone in cui è richiesta la replica. In particolare, deve prima eseguire 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 avere il ruolo volume-replication-admin-global per amministrare la risorsa VolumeReplicationRelationship. Nei casi in cui l'API globale non è disponibile, è possibile utilizzare il ruolo app-volume-replication-admin per modificare direttamente la risorsa VolumeReplicationRelationshipReplica zonale.

Configurare 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 PVC

È richiesto il binding del progetto. Assicurati di aver collegato il 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 zonale.
• 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 a cui connettersi.
• PVC_NAME: il nome della risorsa PersistentVolumeClaim.
• SOURCE_ZONE_NAME: il nome della risorsa Zone di origine.
• DESTINATION_USER_CLUSTER_NAME: il nome della risorsa Cluster utente dell'ambiente di destinazione a cui connettersi.
• DESTINATION_ZONE_NAME: il nome della risorsa Zone 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 un PVC denominato PVC_NAME. Il SOURCE_USER_CLUSTER_NAME è il nome del cluster di origine su cui esiste il PVC e il 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 l'origine e la destinazione della replica dei 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; tuttavia, il campo VolumeOverrideName può essere utilizzato per specificare il nome del PVC creato. Tuttavia, finché non viene creato un VolumeReplicationFailover, il PVC di destinazione rimane di sola lettura e non può essere montato da alcun carico di lavoro.

API disco VM

Replicare 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 in 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 di amministratore di macchine virtuali del progetto. Segui i passaggi per verificare di disporre del ruolo di amministratore di macchine virtuali del progetto (project-vm-admin) nello spazio dei nomi del progetto in cui risiede il disco VM.

Per le operazioni VM che utilizzano l'interfaccia a riga di comando gdcloud, chiedi all'amministratore IAM del progetto di assegnarti sia il ruolo di amministratore di macchine virtuali del progetto sia il ruolo di visualizzatore del progetto (project-viewer).

Avviare 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 zonale.
• VRR_NAME: il nome della risorsa VolumeReplicationRelationship.
• PROJECT: lo spazio dei nomi della risorsa Project.
• SOURCE_ZONE_NAME: il nome della risorsa Zone di origine.
• DESTINATION_ZONE_NAME: il nome della risorsa Zone di destinazione.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: il nome della risorsa VirtualMachineDisk di origine.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: il nome della risorsa VirtualMachineDisk 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 risorsa VirtualMachineDisk denominata VIRTUAL_MACHINE_SOURCE_DISK_NAME per la risorsa VirtualMachine.

I campi source e destination della specifica indicano rispettivamente l'origine e la destinazione della replica dei 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 una VirtualMachineDisk nella zona di destinazione per la scrittura dei dati replicati. Per impostazione predefinita, questa risorsa VirtualMachineDisk ha lo stesso nome della risorsa VirtualMachineDisk di origine; tuttavia, il campo volumeOverrideName può essere utilizzato per specificare il nome della risorsa VirtualMachineDisk creata. Tuttavia, finché non viene creato un VolumeReplicationFailover, la risorsa VirtualMachineDisk di destinazione rimane di sola lettura e non può essere montata da alcun carico di lavoro.

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

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 disco VM

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, questo è il server API di gestione. Per un'organizzazione v1, questo è il cluster di amministrazione dell'organizzazione. Ad esempio, se è stata creata una risorsa VolumeReplicationRelationship che specifica zone2 come zona di destinazione e esiste un PVC o una risorsa 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 il PVC o la risorsa VirtualMachineDisk nella zona di destinazione può essere montato da un carico di lavoro:

  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 zonale.
• VRR_NAME: il nome della risorsa VolumeReplicationRelationship.

• PROJECT: lo spazio dei nomi della risorsa Project.

• Successivamente, un failover riuscito viene visualizzato 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 la creazione del failover, la risorsa VolumeReplicationRelationship my-vrr-repl passa allo stato Broken Off. Il PVC o la risorsa VirtualMachineDisk in zone2 ora può essere montato.

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

  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 disco VM

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 la risorsa VolumeReplicationRelationship, poiché è l'unica azione rimanente che può essere eseguita su questa CR.

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

Ridimensionare i volumi

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

Consulta la documentazione Espandere i dischi VM o Espandere la capacità del volume per ridimensionare lo spazio di archiviazione nelle zone di origine e di destinazione.