Répliquer des volumes de manière asynchrone

Cette page explique comment configurer et effectuer la réplication asynchrone des volumes de stockage par blocs isolés de Google Distributed Cloud (GDC).

La réplication asynchrone est utilisée pour répliquer les données d'une zone GDC vers une autre. Les données répliquées peuvent être utilisées pour le basculement si les données de la zone source deviennent indisponibles. Notez qu'une fois le basculement créé, le volume d'origine ne peut pas être répliqué sur le même volume de destination. À la place, vous devez créer une relation de réplication.

Avant de commencer

Pour activer la réplication asynchrone des blocs entre deux zones, votre opérateur d'infrastructure (OI) doit d'abord établir l'infrastructure de stockage nécessaire en appairant les clusters de stockage concernés de chaque zone. Il doit ensuite associer la machine virtuelle de stockage à l'organisation dans laquelle le stockage par blocs est provisionné.

Ensuite, assurez-vous de disposer du rôle app-volume-replication-admin-global pour administrer la ressource VolumeReplicationRelationship. Si l'API globale n'est pas disponible, le rôle volume-replication-admin peut être utilisé pour modifier directement la ressource VolumeReplicationRelationshipReplica zonale.

Configurer la réplication

La ressource personnalisée (CR) VolumeReplicationRelationship gère l'API de réplication de blocs asynchrone. Cette RS existe dans l'API de gestion globale. Pour activer la réplication d'un périphérique de bloc donné, vous devez créer un CR VolumeReplicationRelationship sur l'API de gestion 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

Cet exemple suppose qu'un projet nommé my-project est créé dans une organisation nommée my-org et qu'un PVC nommé my-block-pvc a déjà été provisionné. clusterRef correspond au nom du cluster sur lequel existe le PVC.

Les champs source et destination de la spécification indiquent respectivement l'emplacement d'origine et de destination des données répliquées. Dans cet exemple, les données sont répliquées de xx-xxxx-zone1 vers xx-xxxx-zone2.

Vérifiez l'état de la relation de réplication en récupérant le CR VolumeReplicationRelationship à partir de l'API globale. Consultez l'exemple suivant. Notez que la sortie a été tronquée pour simplifier :

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

Créer un basculement

Si la zone source n'est pas disponible pour une raison quelconque, un CR VolumeFailover peut être créé dans le plan de gestion de la zone de destination de l'organisation. Pour une organisation V2, il s'agit du serveur de l'API Management. Pour une organisation v1, il s'agit du cluster d'administrateur de l'organisation. Par exemple, si un VolumeReplicationRelationship a été créé et spécifie xx-xxxx-zone2 comme zone de destination et que le PVC existe dans l'organisation my-org, le CR VolumeFailover est créé dans le plan de gestion my-org dans xx-xxxx-zone2. Cela rompt la relation de réplication entre les deux zones et permet à une charge de travail de monter le PVC dans la zone de destination :

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

Une fois le basculement réussi, l'état du CR est mis à jour :

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

Une fois le basculement créé, l'état my-pvc-repl VolumeReplicationRelationship passe à Broken Off. Le PVC dans xx-xxxx-zone2 peut désormais être monté.

À ce stade, VolumeReplicationRelationship devrait ressembler à l'exemple suivant. Encore une fois, cette sortie a été tronquée pour plus de simplicité :

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

Vous pouvez maintenant supprimer la VolumeReplicationRelationship, car il s'agit de la seule action restante pouvant être effectuée sur ce CR.

Redimensionner des volumes

Si le volume source est redimensionné à un moment donné, le volume correspondant dans la zone de destination, qui est créé pour l'utilisateur lorsqu'une relation VolumeReplicatioRelationship est créée, doit également être redimensionné pour correspondre.

Répliquer des disques de machine virtuelle

VolumeReplicationRelationship gère également l'API de réplication asynchrone des disques de machine virtuelle (disques de VM). Le disque source répliqué est appelé disque principal. Le disque de destination sur lequel la réplication est effectuée est appelé disque secondaire. Le démarrage de la réplication asynchrone sur un disque principal crée automatiquement le disque secondaire.

Demander des autorisations et un accès

Pour répliquer des disques de VM, vous devez disposer du rôle Administrateur VirtualMachine du projet. Suivez les étapes pour vérifier que vous disposez du rôle Administrateur VirtualMachine du projet (project-vm-admin) dans l'espace de noms du projet dans lequel réside le disque de la VM.

Pour les opérations sur les VM à l'aide de la gcloud CLI, demandez à l'administrateur IAM de votre projet de vous attribuer le rôle d'administrateur de machines virtuelles du projet et le rôle de lecteur du projet (project-viewer).

Démarrer la réplication asynchrone

Démarrez la réplication asynchrone sur un disque de VM à l'aide de gdcloud ou de 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

Remplacez les éléments suivants :

VariableDéfinition
PRIMARY_DISK_NAME Nom du disque source répliqué.
PROJECT Projet GDC du disque principal.
PRIMARY_ZONE Zone où se trouve le disque principal.
SECONDARY_DISK_NAME Nom du disque de destination sur lequel répliquer les données.
SECONDARY_ZONE Zone dans laquelle le disque secondaire doit résider.

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

Remplacez les éléments suivants :

VariableDéfinition
GLOBAL_MANAGEMENT_API Fichier kubeconfig pour le serveur d'API de gestion globale.
VRR_NAME Nom de la relation de réplication de volume.
Le même nom doit être utilisé pour arrêter la réplication asynchrone.
PROJECT Projet GDC du disque principal.
PRIMARY_DISK_NAME Nom du disque source répliqué.
PRIMARY_ZONE Zone où se trouve le disque principal.
SECONDARY_DISK_NAME Nom du disque de destination sur lequel répliquer les données.
SECONDARY_ZONE Zone dans laquelle le disque secondaire doit résider.

Lister les relations de réplication asynchrone

Répertoriez les relations de réplication asynchrone dans un projet à l'aide de kubectl.

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

Remplacez les éléments suivants :

  • PROJECT : projet GDC du disque principal.
  • GLOBAL_MANAGEMENT_API : fichier kubeconfig pour le serveur d'API de gestion globale.

Le résultat doit se présenter comme suit :

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

Arrêter la réplication asynchrone

Arrêtez la réplication asynchrone sur un disque de VM principal à l'aide de gdcloud ou de kubectl.

gdcloud

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

Remplacez les éléments suivants :

VariableDéfinition
PRIMARY_DISK_NAME Nom du disque source répliqué.
PROJECT Projet GDC du disque principal.
PRIMARY_ZONE Zone où se trouve le disque principal.

API

  1. Recherchez les relations de réplication de volumes correspondant au disque de la VM principale.

    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. Supprimez chacune des relations de réplication de volume listées à l'étape précédente. Remplacez VRR_NAMES par les noms des relations de réplication de volumes.

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

    Remplacez les éléments suivants :

    VariableDéfinition
    GLOBAL_MANAGEMENT_API Fichier kubeconfig pour le serveur d'API de gestion globale.
    PROJECT Projet GDC du disque principal.
    PRIMARY_DISK_NAME Nom du disque source répliqué.
    PRIMARY_ZONE Zone où se trouve le disque principal.

Si la zone source n'est pas disponible pour une raison quelconque, créez un basculement de volume pour arrêter la réplication.

Associer le disque répliqué à une VM

Lorsque la réplication est activée, le disque secondaire ne peut pas être associé à une VM. Une fois la réplication arrêtée, vous pouvez associer le disque secondaire à une VM nouvellement créée ou à une VM existante.