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. Vous devez plutôt créer une relation de réplication.

Pour les administrateurs de plate-forme qui gèrent les PVC à l'aide de l'API KRM, consultez Répliquer des volumes de manière asynchrone.

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 app-volume-replication-admin-global pour administrer la ressource VolumeReplicationRelationship. Dans les cas où 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 Management 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 :

API Replicate PVC

Remarque : La liaison de projet est requise. 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.

Cet exemple suppose 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 correspond au nom du cluster source sur lequel le PVC existe, et DESTINATION_USER_CLUSTER_NAME correspond au nom du cluster de destination sur lequel un nouveau PVC existera.

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 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 l'écriture des données répliquées. Par défaut, ce PVC porte le même nom que le PVC source. Toutefois, vous pouvez utiliser le champ volumeOverrideName pour spécifier le nom du PVC créé. Toutefois, tant qu'un VolumeReplicationFailover n'est pas créé, la PVC de destination reste en lecture seule et ne peut être installée par aucune charge de travail.

Répliquer des disques de machine virtuelle

VolumeReplicationRelationship sert é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 la réplication est effectuée est appelé disque secondaire. Le disque secondaire est créé automatiquement lorsque vous démarrez la réplication asynchrone sur un disque principal.

Demander des autorisations et un accès

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

Pour les opérations sur les machines virtuelles à l'aide de la gcloud CLI, demandez à votre administrateur IAM de projet de vous attribuer à la fois le rôle Administrateur de machines virtuelles du projet et le rôle Lecteur du projet (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

Remplacez les éléments suivants :

Variable	Dé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 effectuer la réplication.
SECONDARY_ZONE	Zone dans laquelle le disque secondaire doit résider.

API VM Disk

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.
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME : nom de la ressource VirtualMachineDisk sur la destination.
• DESTINATION_ZONE_NAME : nom de la ressource de zone de destination.
• VIRTUAL_MACHINE_SOURCE_DISK_NAME : nom de la ressource VirtualMachineDisk sur la source.
• SOURCE_ZONE_NAME : nom de la ressource de zone source.

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 l'emplacement d'origine et de destination des données 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, vous pouvez utiliser le champ volumeOverrideName 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 être installé par aucune charge de travail.

Validation

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

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, 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 zone2 comme zone de destination, et qu'un PVC ou un VirtualMachineDisk existe dans l'organisation my-org, le CR VolumeFailover est créé 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 de monter le PVC ou 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.

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

  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éé, l'my-vrr-repl VolumeReplicationRelationship passe à l'état Broken Off. Le PVC ou VirtualMachineDisk dans zone2 est désormais montable.

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

  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 VolumeReplicationRelationship en toute sécurité, car il s'agit de la seule action restante pouvant être effectuée sur ce CR.

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

Redimensionner des volumes

Si le volume source est redimensionné à un moment donné, vous devez également redimensionner le volume correspondant dans la zone de destination pour qu'il corresponde. Le volume de la zone de destination est créé lorsque vous créez le VolumeReplicationRelationship.

Consultez la documentation Développer des disques de VM ou Développer la capacité des volumes pour redimensionner le stockage dans les zones source et de destination.

Lister les relations de réplication asynchrone

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

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

Remplacez les éléments suivants :

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

La sortie ressemble à ceci :

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 :

Variable	Dé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 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. 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 MANAGEMENT_API_SERVER delete volumereplicationrelationships \
     -n PROJECT VRR_NAMES
   

   Remplacez les éléments suivants :

   Variable	Définition
   MANAGEMENT_API_SERVER	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.