La protection continue des données (CDP) est une technologie qui aide à protéger les machines virtuelles critiques VMware vSphere et VMware vCloud Director lorsque la perte de données pendant quelques secondes ou minutes est inacceptable.
La fonctionnalité CDP offre également un objectif de temps de récupération (RTO) minimal en cas de sinistre, car les réplicas sont dans un état prêt à démarrer.
Réplication des données
Tout d'abord, la réplication CDP crée des réplicas et, ensuite, maintient ces réplicas à jour.
La fonctionnalité CDP réplique en continu les opérations d'E/S effectuées sur les VMs. Pour lire et traiter les opérations d'E/S en transit entre les VMs protégées et leur datastore de production, CDP utilise les API vSphere de filtrage des E/S (VAIO) qui offrent la possibilité de ne pas créer de snapshot.
Comme CDP est toujours active et ne crée pas de snapshot, elle permet d'atteindre un objectif de point de récupération (RPO) plus faible que la réplication basée sur les snapshots - un RPO proche de zéro, ce qui signifie une perte de données quasi nulle.
Les données des opérations d'E/S sont stockées sur le datastore cible et représentent les Short-Term Retention Point.
Les points de restauration Short-Term permettent de restaurer une VM dans un état datant de quelques secondes ou minutes (selon le RPO spécifié) en cas de sinistre. Les informations sur les points de restauration Short-Term sont conservées dans un journal dédié. Ce journal conserve les enregistrements des points de restauration Short-Term pendant 24 heures maximum. Pour restaurer une VM dans un état plus ancien, Veeam Backup & Replication permet de créer des points de restauration suppémentaires qui contiennent un état de la VM remontant à plusieurs heures ou jours. Ces points de restauration sont appelés Long-Term Retention Point.
Restauration des données
Pour restaurer une VM depuis un point de restauration Short-Term ou Long-Term, il faut basculer sur son réplica.
Lors de la bascule sur un réplica, celui-ci reprend le rôle de la VM d'origine. Une fois la machine virtuelle d'origine restaurée, il est possible d’y revenir et de retransférer toutes les modifications apportées au réplica vers celle-ci.
Si la VM d'origine ne peut pas être restaurée, il est possible d’effectuer un Permanent Failover, c'est-à-dire passer de façon définitive de la VM d'origine à son réplica et utiliser ce réplica comme nouvelle VM d'origine. (cf. Chapitre Failover et Failback pour CDP).
Il est également possible d'effectuer les restaurations suivantes depuis un réplica CDP:
File-level recovery
Application item-level recovery
Tests de restauration SureReplica
De plus, l'I/O Anomaly Visualizer permet d'effectuer une reprise point-in-time juste avant une infection par un logiciel malveillant ou une cyberattaque. En effet, cet outil Veeam aide à sélectionner le meilleur moment pour basculer (juste avant l'explosion de l'activité d'E/S), garantissant ainsi la perte de données la plus faible possible.
Les opérations de Failover et Failback aident à garantir qu’une entreprise fonctionnera même si un sinistre frappe son site de production. Le Failover est un processus qui consiste à passer de la VM d'origine sur l'hôte source à son réplica sur un hôte du site de secours. Le Failback est un processus de retour du réplica à la VM d'origine.
Veeam Backup & Replication propose les opérations de Failover et Failback suivantes :
Le Failover est un processus qui consiste à passer de la VM d'origine sur l'hôte source à son réplica sur l'hôte cible.
Pendant le Failover, Veeam Backup & Replication remet en production une VM entièrement fonctionnelle depuis un point de restauration sur l'hôte cible. Ainsi, la VM est opérationnelle en quelques secondes, et les utilisateurs peuvent accéder aux services et applications dont ils ont besoin avec un minimum d'interruption.
La bascule de réplicas peut être effectuée non seulement lorsqu'un sinistre frappe le site de production, mais aussi pour tester la capacité de récupération des réplicas.
(Si les machines virtuelles sources et les réplicas de machines virtuelles se trouvent sur le même réseau, il faudra déconnecter temporairement les machines virtuelles sources du réseau pour éviter les conflits d'adresses IP ou de noms de machines.)
Quand un Failover est lancé, l'état de la VM d'origine sur l'hôte source n'est en aucun cas affecté.
Dans un scénario de reprise après sinistre, après avoir testé le réplica et s'être assuré que la VM fonctionne de manière stable, il est nécessaire de passer à une autre étape pour effectuer un Failover permanent.
Dans le cas d’un nombre important de VMs exécutant des applications interdépendantes, il est important de pouvoir basculer ces VMs sur le site distant une par une, dans un ordre bien défini, comme faisant parties d'un même groupe applicatif. Pour effectuer cette opération automatiquement, Veeam Backup & Replication permet de préparer un Failover Plan.
Un Failover Plan permet de définir l'ordre dans lequel les VMs doivent être redémarrées ainsi que l’intervalle de temps devant être respecter entre chacune d'elles. Cet intervalle de temps permet de s'assurer que certaines VMs, comme un serveur DNS, sont déjà en cours d'exécution au moment où les VMs dépendantes démarrent. Le délai est défini pour chaque VM du Failover Plan, à l'exception de la dernière VM de la liste.
Un CDP réplica peut être ajouté à un nouveau Failover Plan comme à un Failover Plan existant.
Le Planned Failover est un processus par lequel l'administrateur lance manuellement le basculement d'une VM source vers son répliqua avec un minimum d'interruption de service.
Le Planned Failover est utile lorsque les machines virtuelles de production sont sur le point d'être mises hors ligne et que l'administrateur doit basculer de manière proactive la charge de travail des machines virtuelles sources vers leurs réplicas.
Le planned Failover peut être utilisé, par exemple, pour effectuer une migration du Datacenter, une maintenance ou une mise à niveau logicielle des machines virtuelles de production. Il peut être également utilisé dans le cas de signes annonciateurs d'un désastre imminent.
Le Permanent Failover est l'un des deux moyens de finaliser un Failover (il est possible d’effectuer un Permanent Failover ou un Failback, cf partie suivante). Pour finaliser le processus de Failover, Veeam Backup & Replication permet la bascule permanente vers le réplica.
L’opération de Permanent Failover peut être effectuée dans le cas où l’administrateur souhaite passer de façon définitive de la VM d'origine à un réplica et utiliser ce réplica comme nouvelle VM d'origine. À la suite du Permanent Failover, le réplica cesse d'exister en tant que réplica et reprend le rôle de la VM d'origine.
Pour ramener un réplica à son état antérieur au Failover, il est tout simplement possible d’annuler ce Failover.
Lorsque l'Undo Failover est lancé, l'administrateur repasse du réplica à la VM d’origine. Veeam Backup & Replication annule toutes les modifications apportées au réplica pendant qu'il était en état “Failover”. Le scénario d’Undo Failover est utilisé dans le cas où le réplica est utilisé à des fins de tests ou de troubleshoot et qu'il faut revenir au mode opérationnel nominal.
Le Failback est l'un des deux moyens de finaliser un Failover. Lors d'un Failback, l'administrateur revient à la VM de production à partir du replica de VM, en déplaçant les E/S du site DR vers le site de production.
Veeam Backup & Replication propose les options suivantes pour effectuer un retour arrière (Failback) :
Revenir à la VM d'origine dans l'emplacement d'origine.
Effectuer un Failback sur une VM déjà restaurée vers un nouvel emplacement. Cette VM doit être restaurée avant d'effectuer un Failback. Par exemple, une VM restaurée depuis une sauvegarde.
Effectuer un Failback sur une VM restaurée à partir d'un réplica vers un nouvel emplacement, ou vers n'importe quel emplacement mais avec des paramètres différents. La VM sera restaurée à partir du réplica pendant le processus de retour en arrière.
Les deux premières options permettent de réduire le temps de restauration et l'utilisation du trafic réseau car Veeam Backup & Replication n'a besoin de transférer que les différences entre la VM originale/restaurée et le réplica. Concernant la troisième option, Veeam Backup & Replication doit transférer l'ensemble des données de la VM, y compris sa configuration et le contenu du disque virtuel.
Il est préférable d’utiliser la troisième option seulement s’il n’est pas possible d'utiliser la VM originale ou de la restaurer à partir d'une sauvegarde.
Lors d’un Failback, les changements sont uniquement envoyés à la VM originale/restaurée mais ne sont pas publiés. La VM originale/restaurée doit être testée pour vérifier si elle fonctionne avec ces changements.
En fonction des résultats du test, il est possible de procéder comme suit :
Lorsque le failback est validé, cela confirme le fait de revenir sur la VM originale. Veeam Backup & Replication revient au mode de fonctionnement normal et reprend les activités de réplication pour la VM d'origine sur laquelle le retour arrière a été confirmé.
Si la VM d'origine ne fonctionne pas comme prévu après l'opération de failback, il est tout simplement possible d’annuler le Failback et revenir sur le réplica.
Pour mettre en place une architecture CDP, les composants suivants sont nécessaires :
Serveur de sauvegarde
Hôtes source et cible
Proxies CDP VMware
Le serveur de sauvegarde est la console de configuration, d'administration et de gestion de l'infrastructure de sauvegarde. Le serveur de sauvegarde exécute le service Veeam CDP Coordinator. Ce service coordonne les tâches de réplication et de transfert de données, et contrôle l'allocation des ressources.
Les hôtes source et cible sont deux points terminaux entre lesquels les données des VM répliquées sont envoyées. Les hôtes source et cible peuvent faire partie du même cluster ou de deux clusters différents. Les clusters peuvent être gérés par le même serveur vCenter ou par deux serveurs vCenter différents connectés au même serveur de sauvegarde.
Les hôtes source et cible effectuent les tâches suivantes :
L'hôte source lit les données du disque virtuel de la VM, lit et traite les opérations d'E/S et envoie les données aux proxies source. Ces données sont envoyées sans être compressées.
L'hôte cible reçoit les données des proxies cibles et enregistre ces données dans les réplicas sur leur datastore. L’hôte cible gère les réplicas : il crée des réplicas, conserve les points de restauration, etc.
Pour pouvoir utiliser les hôtes dans le cadre d’une réplication CDP, il faut installer l'I/O Filter sur chaque cluster où résident les hôtes. Après avoir installé l'I/O Filter sur les clusters, Veeam Backup & Replication installe automatiquement le filtre sur tous les hôtes ajoutés aux clusters.
L’I/O Filter lit et traite les opérations d'entrées/sorties en transit entre les VM protégées et leur datastore et envoie/reçoit les données vers/depuis les Proxies VMware CDP. De plus, le filtre communique avec le service Veeam CDP Coordinator sur le serveur de sauvegarde et notifie à ce service que l'infrastructure de sauvegarde doit être reconfigurée si un Proxy devient indisponible. L'I/O Filter est construit sur la base de vSphere API for I/O filtering (VAIO).
Un Proxy CDP VMware est un composant qui fonctionne comme un transmetteur de données entre les hôtes source et cible. Il est recommandé de configurer au moins deux Proxies CDP VMware : un (Proxy source) sur le site de production et un (Proxy cible) sur le site de DR.
Les Proxies CDP VMware source et cible effectuent les tâches suivantes :
Le Proxy source prépare les données des points de restauration Short-Term à partir des données reçues de l'hôte source, compresse et chiffre les données (si le chiffrage est activé dans les règles de trafic réseau). Il les envoie ensuite au Proxy cible.
Le Proxy cible reçoit les données, les décompresse et les déchiffre, puis les envoie à l'hôte cible.
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.