Répliquer des volumes de manière asynchrone

Cette page vous explique comment configurer et effectuer une réplication asynchrone des volumes de stockage de blocs Google Distributed Cloud (GDC) avec isolation physique.

La réplication asynchrone permet de répliquer des données d'une zone GDC à une autre. Ces données répliquées peuvent être utilisées dans un scénario de basculement si les données de la zone source ne sont pas disponibles. Notez qu'une fois le basculement créé, le volume d'origine ne peut pas être configuré pour être répliqué sur le même volume de destination. Vous devez créer une relation de réplication.

Pour les opérateurs d'application qui préfèrent utiliser la CLI gdcloud, consultez Répliquer des volumes de manière asynchrone pour les opérateurs d'application.

Avant de commencer

Pour utiliser la réplication de blocs asynchrone, votre opérateur d'infrastructure (IO) doit d'abord configurer deux zones pour la réplication asynchrone.

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

Configurer la réplication

La ressource personnalisée VolumeReplicationRelationship gère l'API de réplication de blocs asynchrone. Cette ressource personnalisée existe dans l'API de gestion globale. Pour activer la réplication pour un appareil de stockage en mode bloc donné, une ressource personnalisée VolumeReplicationRelationship doit être créée sur l'API Management globale :

API PVC

Veuillez indiquer une liaison de projet. Assurez-vous d'avoir associé votre projet à chaque ressource de cluster dans chaque zone participante.

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

Remplacez les éléments suivants :

• MANAGEMENT_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API zonal.
• VRR_NAME : nom de la ressource VolumeReplicationRelationship.
• PROJECT : espace de noms de la ressource Project.
• SOURCE_USER_CLUSTER_NAME : nom de la ressource de cluster d'utilisateur source à connecter.
• PVC_NAME : nom de la ressource PersistentVolumeClaim.
• SOURCE_ZONE_NAME : nom de la ressource de zone source.
• DESTINATION_USER_CLUSTER_NAME : nom de la ressource de cluster d'utilisateur de destination à connecter.
• DESTINATION_ZONE_NAME : nom de la ressource de zone de destination.

Dans cet exemple, nous partons du principe qu'un projet nommé PROJECT est créé dans une organisation nommée my-org et qu'un PVC nommé PVC_NAME a déjà été provisionné. SOURCE_USER_CLUSTER_NAME est le nom du cluster source sur lequel se trouve le PVC, et DESTINATION_USER_CLUSTER_NAME est le nom du cluster de destination où un nouveau PVC sera créé.

Les champs source et destination de la spécification indiquent respectivement depuis et vers où les données sont répliquées. Dans cet exemple, les données sont répliquées de SOURCE_ZONE_NAME vers DESTINATION_ZONE_NAME.

Remarque : Le service de réplication de blocs asynchrone crée automatiquement un PVC dans la zone de destination pour écrire les données répliquées. Par défaut, cette PVC porte le même nom que la PVC source. Toutefois, le champ VolumeOverrideName peut être utilisé pour spécifier le nom de la PVC créée. Toutefois, tant qu'un VolumeReplicationFailover n'est pas créé, la PVC de destination reste en lecture seule et ne peut pas être installée par des charges de travail.

API VM Disk

Répliquer des disques de machine virtuelle

VolumeReplicationRelationship gère également l'API de réplication asynchrone des disques de machines virtuelles (disques de VM). Le disque source répliqué est appelé "disque principal". Le disque de destination sur lequel les données sont répliquées 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 d'administrateur de machines virtuelles du projet. Suivez la procédure pour vérifier que vous disposez du rôle d'administrateur de machine virtuelle de projet (project-vm-admin) dans l'espace de noms du projet où se trouve le disque de la VM.

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

Démarrer la réplication asynchrone

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

Remplacez les éléments suivants :

• MANAGEMENT_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API zonal.
• VRR_NAME : nom de la ressource VolumeReplicationRelationship.
• PROJECT : espace de noms de la ressource Project.
• SOURCE_ZONE_NAME : nom de la ressource de zone source.
• DESTINATION_ZONE_NAME : nom de la ressource de zone de destination.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME : nom de la ressource VirtualMachineDisk sur la source.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME : nom de la ressource VirtualMachineDisk sur la destination.

Cet exemple suppose qu'un projet nommé PROJECT est créé dans une organisation nommée my-org et qu'un VirtualMachineDisk nommé VIRTUAL_MACHINE_SOURCE_DISK_NAME a déjà été provisionné pour la ressource VirtualMachine.

Les champs source et destination de la spécification indiquent respectivement depuis et vers où les données sont répliquées. Dans cet exemple, les données sont répliquées de SOURCE_ZONE_NAME vers DESTINATION_ZONE_NAME.

Remarque : Le service de réplication de blocs asynchrone crée automatiquement un VirtualMachineDisk dans la zone de destination pour écrire les données répliquées. Par défaut, ce VirtualMachineDisk porte le même nom que le VirtualMachineDisk source. Toutefois, le champ volumeOverrideName peut être utilisé pour spécifier le nom du VirtualMachineDisk créé. Toutefois, tant qu'un VolumeReplicationFailover n'est pas créé, le VirtualMachineDisk de destination reste en lecture seule et ne peut pas être installé par des charges de travail.

Validation

Vérifiez l'état de la relation de réplication en récupérant la ressource personnalisée VolumeReplicationRelationship à partir de l'API globale. Référez-vous à l'exemple suivant. Notez que le résultat a été tronqué pour plus de simplicité :

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

Le résultat ressemble à ce qui suit :

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

Créer un basculement

Si la zone source n'est pas disponible pour une raison quelconque, une CR VolumeFailover peut être créée dans le plan de gestion de l'organisation de la zone de destination. Pour une organisation v2, il s'agit du serveur d'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 zone2 comme zone de destination, et qu'un PVC ou un VirtualMachineDisk existe dans l'organisation my-org, la CR VolumeFailover est créée dans le plan de gestion my-org dans zone2. Cela rompt la relation de réplication entre les deux zones et permet à une charge de travail d'installer le PVC ou le VirtualMachineDisk dans la zone de destination :

  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

Remplacez les éléments suivants :

• FAILOVER_NAME : nom de la ressource VolumeFailover.
• MANAGEMENT_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API zonal.
• VRR_NAME : nom de la ressource VolumeReplicationRelationship.

• PROJECT : espace de noms de la ressource Project.

• Ensuite, un basculement réussi est reflété dans l'état de la CR :

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

• Le résultat ressemble à ce qui suit :

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

• Une fois le basculement créé, le VolumeReplicationRelationship my-vrr-repl passe à l'état Broken Off. Le PVC ou le VirtualMachineDisk dans zone2 peut désormais être installé.

• À ce stade, le fichier VolumeReplicationRelationship doit ressembler à l'exemple suivant. Encore une fois, ce résultat a été tronqué pour plus de simplicité :

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

• Le résultat ressemble à ce qui suit :

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

• Vous pouvez maintenant supprimer la ressource personnalisée VolumeReplicationRelationship en toute sécurité, car il s'agit de la seule action restante possible sur cette ressource personnalisée.

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

Redimensionner des volumes

Si le volume source est redimensionné à un moment donné, le volume correspondant dans la zone de destination, qui est créé au nom de l'utilisateur lors de la création d'un VolumeReplicationRelationship, doit également être redimensionné en conséquence.

Consultez la documentation Étendre des disques de VM ou Étendre la capacité d'un volume pour redimensionner l'espace de stockage dans les zones source et de destination.