NetApp Disaster Recovery est un service de reprise après sinistre basé sur le cloud, accessible via la NetApp Console, qui automatise les workflows de reprise après sinistre pour les environnements VMware et Kubernetes. Il réplique les charges de travail VMware sur site exécutant un stockage ONTAP, ou les charges de travail Kubernetes exécutant un stockage ONTAP géré par Trident, vers un autre site servant de cible de reprise après sinistre. Le service utilise la technologie ONTAP SnapMirror, avec l'orchestration native VMware ou l'orchestration Trident Protect, afin de protéger les charges de travail tout en préservant les efficacités de stockage ONTAP telles que la compression et la déduplication.

La reprise après sinistre ne nécessite aucune activation séparée. Elle apparaît automatiquement dans la navigation de gauche de la NetApp Console, sous Protection > Disaster recovery. Pour accéder à la NetApp Console, dans un navigateur, saisissez : "https://console.netapp.com/".

Une licence NetApp Disaster Recovery est requise pour un accès complet et continu. Vous pouvez essayer le service avec un essai gratuit de 30 jours avant d’acheter une licence ou un abonnement. Pour plus de détails, consultez "Configurer la licence NetApp Disaster Recovery".

La reprise après sinistre prend en charge les cibles de protection suivantes :

Pour les charges de travail VMware, NetApp Disaster Recovery prend en charge les types de banques de données suivants :

Pour les charges de travail Kubernetes, la reprise après sinistre protège les volumes persistants provisionnés via NetApp Trident sur le stockage ONTAP.

NetApp Disaster Recovery propose les options de licence suivantes :

Les frais de reprise après sinistre sont calculés en fonction de la capacité utilisée des datastores sur le site source lorsqu'il existe au moins une machine virtuelle ou une ressource Kubernetes disposant d'un plan de réplication.

Pour un service BYOL, si les données dépassent la capacité autorisée, les opérations sur le service sont limitées jusqu'à ce que vous obteniez une licence de capacité supplémentaire ou que vous mettiez à niveau la licence dans la NetApp Console.

Après la fin de la période d'essai gratuite, vous pouvez toujours consulter et supprimer des ressources telles que les charges de travail et les plans de réplication, et exécuter toutes les opérations planifiées créées pendant la période d'essai. Pour continuer à utiliser le service avec toute la fonctionnalité, vous devez obtenir soit un abonnement PAYGO auprès de votre fournisseur de cloud, soit acheter une licence BYOL auprès de NetApp.

Vous pouvez acheter une licence ou vous abonner à tout moment et vous ne serez facturé qu'à la fin de la période d'essai de 30 jours.

La reprise après sinistre prend en charge les topologies suivantes :

Pour la liste complète, voir "Prérequis pour la reprise après sinistre".

Un agent Console est un composant logiciel qui permet à la NetApp Console de communiquer avec vos clusters de stockage ONTAP et VMware vCenter. Il est requis pour que la reprise après sinistre fonctionne correctement. L’agent réside dans votre réseau privé (soit un centre de données sur site, soit un VPC cloud) et communique avec vos instances de stockage ONTAP et vos clusters vCenter.

Pour une reprise après sinistre entre environnements locaux, installez l'agent Console local sur le site de reprise après sinistre. Pour une reprise après sinistre vers AWS, installez l'agent Console pour AWS dans votre VPC AWS. Les clusters vCenter source et de destination doivent utiliser le même agent Console. La reprise après sinistre fonctionne uniquement avec le déploiement de l'agent en mode standard.

Chaque cluster Kubernetes doit avoir NetApp Trident installé, un backend ONTAP et une classe de stockage configurés, ainsi que les CRD de snapshots de volumes et le contrôleur installés. Les applications doivent utiliser des volumes persistants provisionnés via la classe de stockage Trident. Lorsque vous ajoutez un cluster Kubernetes en tant que site, NetApp Disaster Recovery vous guide pour installer et enregistrer Trident Protect sur ce cluster. Voir "Exigences relatives au cluster Kubernetes pour la reprise après sinistre" pour les commandes étape par étape et les vérifications.

Un site est un conteneur logique, généralement associé à un centre de données physique ou à un emplacement cloud, qui héberge un ou plusieurs clusters vCenter ou clusters Kubernetes. Vous ajoutez à la fois un site source (production) et un site de destination (reprise après sinistre) avant de créer un plan de réplication.

Un groupe de ressources est un conteneur logique qui vous permet de gérer plusieurs machines virtuelles, banques de données ou espaces de noms et ressources Kubernetes comme une seule unité, afin qu'elles puissent être protégées à l'aide d'un instantané commun. Une machine virtuelle ne peut appartenir qu'à un seul groupe de ressources à la fois. Vous pouvez créer un groupe de ressources pour chaque application ou charge de travail que vous souhaitez protéger, et les machines virtuelles s'allument selon l'ordre de démarrage que vous configurez au sein du groupe.

Un plan de réplication est un ensemble de règles définissant la fréquence des sauvegardes et la gestion des événements de basculement. Il sélectionne les sites source et de destination, attribue les groupes de ressources, définit les mappages de récupération et configure le comportement à la mise sous tension. Les plans définissent l'objectif de point de récupération (RPO) en fonction de la fréquence de la réplication des données.

L'objectif de point de récupération (RPO) correspond à la quantité maximale de perte de données acceptable en cas de sinistre ; il est défini par la fréquence ou la planification de réplication du plan de réplication. L'objectif de temps de récupération (RTO) correspond au délai maximal acceptable pour la récupération après un sinistre ; il est déterminé par le temps nécessaire pour basculer vers le site de reprise d'activité et redémarrer toutes les machines virtuelles ou applications.

Pour connaître les étapes, voir "Ajouter des sites dans la reprise après sinistre".

La découverte s'exécute par défaut toutes les 24 heures ; vous pouvez personnaliser la planification en fonction de votre environnement. L'intervalle minimum est de 30 minutes et le maximum est de 24 heures. NetApp recommande d'effectuer d'abord quelques découvertes manuelles pour obtenir des informations à jour, puis de configurer la planification pour une exécution automatique. Les ressources nouvellement ajoutées ou supprimées sont reconnues lors de la prochaine découverte planifiée ou manuelle.

Non. Héberger des machines virtuelles protégées et non protégées sur le même datastore peut engendrer des problèmes. En effet, si le datastore fait l'objet d'un basculement, toutes les machines virtuelles non protégées qui s'y trouvent n'existent plus à la source après le basculement, et NetApp Disaster Recovery ne les démarrera pas sur le site de basculement.

Vous devez organiser les ressources avant de déployer NetApp Disaster Recovery afin que les charges de travail protégées et non protégées utilisent des sous-ensembles distincts de banques de données, et vous assurer qu'une même banque de données n'est pas protégée par plus d'un plan de réplication.

Si vous prévoyez d'utiliser des sauvegardes gérées par la plateforme (gérées par ONTAP), utilisez la stratégie MirrorAll. MirrorVault et Asynchronous sont des alternatives acceptables, mais vous devez vous assurer que l'instantané sélectionné lors du basculement ou du retour arrière existe sur les volumes source et de destination, sinon l'opération échouera avec une erreur « no common snapshot found ». MirrorLatest n'est pas recommandée car elle ne laisse qu'un seul instantané commun pour le basculement. Pour les relations SnapMirror gérées par NetApp Disaster Recovery, ne planifiez pas de mises à jour en dehors du service, car NetApp Disaster Recovery gère la planification de la réplication.

Oui. Si une relation SnapMirror existe déjà entre les volumes source et de destination d'une banque de données protégée, la reprise après sinistre utilise cette relation pour toutes les opérations de réplication au lieu d'en créer une nouvelle.

Oui. Vous pouvez migrer des applications VMware d'un site source vers un autre site à l'aide d'un plan de réplication configuré pour la migration. Après avoir lancé la migration, le service vérifie toutes les 30 minutes que la migration progresse conformément au plan ; vous pouvez suivre la progression dans la surveillance des tâches. La migration n'est actuellement pas prise en charge pour les charges de travail basées sur Kubernetes. Voir "Migrer les applications vers un autre site".

Oui. Lors d'un test de basculement, NetApp Disaster Recovery crée des machines virtuelles temporaires à partir d'un nouveau volume FlexClone de l'instantané sélectionné et mappe un datastore temporaire basé sur FlexClone aux hôtes ESXi. Cette opération ne consomme pas de capacité physique supplémentaire, ne modifie pas le volume source d'origine et ne perturbe ni la relation SnapMirror ni les charges de travail de production, qui continuent de se répliquer normalement. Après le test, nettoyez l'environnement de test à l'aide de l'action Nettoyer le test de basculement. Voir "Basculer les applications vers un site distant".

Oui. Par défaut, toutes les machines virtuelles démarrent ensemble en parallèle, mais vous pouvez attribuer à chaque machine virtuelle un numéro séquentiel (par exemple, 1, 2, 3) pour contrôler l’ordre de démarrage, ou attribuer le même numéro à plusieurs machines virtuelles pour les démarrer simultanément. Vous pouvez également définir un délai de démarrage (0 à 10 minutes) par machine virtuelle afin d’échelonner le démarrage, ce qui est utile pour garantir que les machines virtuelles prioritaires soient en cours d’exécution avant le démarrage des machines virtuelles de priorité inférieure.

La restauration des opérations (Failback) rétablit le fonctionnement du site source d'origine après la résolution d'un sinistre. À partir d'une relation ayant basculé vers la cible, NetApp Disaster Recovery resynchronise les modifications avec la machine virtuelle ou le cluster Kubernetes source d'origine avant d'inverser le sens de la réplication. Processus :

Voir "Rétablissez les applications sur la source d'origine".

Utilisez le tableau de bord de reprise après sinistre pour vérifier si les sites et les plans sont sains, déconnectés ou dégradés ; examiner les avertissements récents et les tâches ayant échoué ; identifier les charges de travail protégées et non protégées ; et visualiser la capacité en un coup d'œil. Voir "Afficher l'état de santé du plan de reprise après sinistre".

Utilisez la fonction Surveillance des tâches pour consulter l'horodatage, l'état et l'initiateur des tâches (ou « système » si NetApp Disaster Recovery les a lancées). Vous pouvez annuler une tâche « En cours » ou « En file d'attente » depuis son menu Actions, ce qui est utile si une tâche est bloquée ou si vous devez prioriser une autre opération. Voir "Surveillez les tâches de reprise après sinistre".

Vous pouvez générer des rapports limités à VMware, Kubernetes ou à l'ensemble des charges de travail, couvrant les détails du plan de réplication, l'état de conformité et les résumés des tâches. Les rapports peuvent être téléchargés aux formats PDF, HTML ou JSON. Ils couvrent une période de un à sept jours. Pour plus d'informations, voir "Créer des rapports dans NetApp Disaster Recovery".

Un AppVault est la cible de stockage cloud où Trident Protect enregistre les données de protection Kubernetes. Vous créez un AppVault lors de la configuration d'un plan de réplication Kubernetes.