Comment fonctionne la CDP?
Dernière mise à jour
Cet article vous a-t-il été utile ?
Dernière mise à jour
Cet article vous a-t-il été utile ?
Le workflow CDP pendant la réplication est divisé en deux parties : la configuration des composants de l'infrastructure de sauvegarde et le transfert des données.
Pendant la configuration, Veeam Backup & Replication configure les composants de l'infrastructure de sauvegarde requis. Veeam Backup & Replication reconfigure également les composants si quelque chose change dans l'infrastructure. Pendant le transfert des données, Veeam Backup & Replication crée des points de restauration Short-Term et Long-Term en envoyant l'ensemble des blocs de données et changements effectués sur les vdisk protégés.
Une politique de rétention définit pendant combien de temps Veeam Backup & Replication doit stocker les points de restauration des réplicas CDP. Veeam Backup & Replication propose deux schémas de politique de rétention :
Short-Term
Long-Term
Veeam Backup & Replication conserve les points de restauration Long-Term pendant le nombre de jours spécifié dans les paramètres de la politique CDP. Lorsque la période de rétention est dépassée, Veeam Backup & Replication transforme la chaîne de réplication de la manière suivante.
L'exemple montre comment la rétention à long terme fonctionne pour un réplica avec un unique disque virtuel.
1.Veeam Backup & Replication vérifie si la chaîne de réplication contient des points de restauration Long-Term périmés.
2. Si un point de restauration périmé existe, Veeam Backup & Replication commit le fichier qui contient les données du disque de base (-flat.vmdk) pour inclure les données du fichier qui contient les données du disque delta (-.vmdk). Pour ce faire, Veeam Backup & Replication inclus dans le fichier du disque de base les données du fichier du disque delta le plus ancien. De cette façon, le fichier du disque de base " avance " au sein de la chaîne de réplication.
3. Veeam Backup & Replication supprime le fichier disque delta le plus ancien de la chaîne comme étant redondant - ces données sont déjà présentes dans le fichier disque de base.
Veeam Backup & Replication conserve les points de restauration short-Term pendant le nombre d'heures spécifié dans les paramètres de la politique CDP. Lorsque la période de rétention est dépassée, Veeam Backup & Replication transforme la chaîne de réplication de la manière suivante.
L'exemple montre comment la rétention à court terme fonctionne pour un réplica de VM avec un unique disque virtuel.
Veeam Backup & Replication vérifie si la chaîne de réplication contient des points de restauration Short-Term périmés.
Si un point de restauration périmé existe, Veeam Backup & Replication commit les données pour ce point de restauration à partir du fichier transaction log (.tlog) dans le fichier de disque delta ou de base le plus proche (-flat.vmdk ou -.vmdk).
Si le fichier transaction log ne contient pas de données pour d'autres points de restauration, Veeam Backup & Replication supprime le fichier transaction log redondant - ces données ont déjà été incluses dans un fichier disque de base ou delta.
En réplication CDP, la transmission des données entre deux composants de l'infrastructure de sauvegarde est garantie par le protocole TCP. Cependant, il peut y avoir des situations où Veeam Backup & Replication n'est pas en mesure d'envoyer à temps tous les changements de données générés pendant la réplication CDP. Par exemple, dans le cas d'un RPO faible où une VM génère beaucoup de changements, mais les performances de l'infrastructure ne sont pas suffisantes ; ou bien un Proxy CDP VMware est hors service à cause d'une panne de courant. Tous les changements de données stockés sur celui-ci sont perdus. Cela rend les données incohérentes et entraîne la perte des points de restauration.
La fonctionnalité de CDP dispose d'un mécanisme et d'outils spéciaux qui remettent les données dans un état cohérent.
L'I/O Filter de l'hôte source dispose d'un mécanisme de suivi des blocs de données qui ont été modifiés - Change Tracking (CT). L'I/O Filter ne supprime les pointeurs des blocs de données de la liste des blocs modifiés qu'après avoir reçu de l'hôte cible un message de confirmation indiquant que les blocs de données ont été enregistrés avec succès sur le réplica. De plus, les Proxy VMware CDP stockent également les modifications de données jusqu'à ce qu'un message de confirmation soit reçu de l'hôte cible.
La façon dont Veeam Backup & Replication utilise ces outils dépend du fait que les problèmes se produisent sur le site source ou cible :
Site source. Si l'hôte source n'envoie pas les modifications de données en raison de la charge élevée du système, Veeam Backup & Replication attend que la charge diminue. Ensuite, il obtient la liste des blocs de données modifiés, lit les blocs de données sur le disque et envoie les données à l'hôte cible. L'hôte cible enregistre les données reçues dans le datastore. Jusqu'à ce moment, les données sur l'hôte cible restent incohérentes. Par conséquent, il y a des "trous" dans le journal des points de restauration et il ne sera pas possible de restaurer depuis ces points manquants. Cependant, une fois que l'hôte cible a sauvegardé les données, la politique CDP reprend la création de points de restauration cohérents. Si le Proxy source est en panne, Veeam Backup & Replication sélectionne un autre Proxy VMware CDP et se comporte alors comme décrit ci-dessus, à l'exception de l'attente de la diminution de la charge.
Site cible. Si le Proxy cible est en panne, Veeam Backup & Replication sélectionne un autre Proxy CDP VMware et redemande les modifications de données au Proxy CDP VMware source. Le Proxy envoie à nouveau les modifications à l'hôte cible, et les données sur l'hôte cible deviennent cohérentes presque immédiatement, de sorte d’être en mesure de restaurer une VM à n'importe quel point dans le temps. Si la connexion entre le Proxy VMware CDP cible et l'hôte cible est perdue, Veeam Backup & Replication vérifie l'état de l'hôte. Si l'hôte est en mode maintenance ou a disparu du cluster, Veeam Backup & Replication commence à écrire les modifications de données sur les réplicas en utilisant un autre hôte ESXi cible (à condition que l'hôte existe et soit connecté au datastore où sont stockées les réplicas). Si l'hôte n'est pas en mode maintenance ou n'a pas disparu, Veeam Backup & Replication considère qu'il s'agit de problèmes temporaires avec le réseau et envoie à nouveau les changements de données après un certain temps.
Le Replica Seeding et le mapping sont des technologies qui permettent de réduire la quantité de trafic envoyé sur le réseau. Grâce à ces technologies, Veeam Backup & Replication n'a pas besoin de transférer toutes les données des machines virtuelles de l'hôte source à l'hôte cible à travers les sites lors de la synchronisation initiale.
Vous pouvez utiliser le seeding et le mapping dans les scénarios suivants :
Seeding : Un Replica Seeding peut être configuré si, dans un Repository de sauvegarde situé sur le site de reprise après sinistre (DR), des sauvegardes de VM qu’il est prévu de répliquer sont disponibles. Pendant la réplication, Veeam Backup & Replication restaurera les machines virtuelles à partir de ces sauvegardes et synchronisera l'état des machines virtuelles restaurées avec le dernier état des machines virtuelles d'origine. Ensuite, Veeam Backup & Replication utilisera ces VMs restaurées comme réplicas.
Mapping : Un Replica Mapping peut être configuré si, sur l'hôte du site DR, des copies prêtes à l'emploi des VMs d'origine sont présentes. Il peut s'agir de VMs restaurées ou de réplicas créés par d'autres politiques CDP. Veeam Backup & Replication synchronisera l'état de ces VMs prêtes à l'emploi avec le dernier état des VMs originales et utilisera ces VMs comme réplicas. Il est également possible de configurer à la fois le Replica Seeding et le Replica Mapping dans la même politique CDP. Par exemple, si une politique comprend deux VMs, vous pouvez utiliser le seeding pour une VM et le mapping pour l'autre VM sur une VM existante.
Important : Si le seeding ou le mapping est activé dans une politique, toutes les VM de la politique doivent être couvertes par le seeding ou le mapping. Si une VM n'a pas de seeding ou n'est pas mappée à une VM existante, elle ne sera pas traitée.
