Conditions préalables à la NetApp Disaster Recovery
Avant d'utiliser NetApp Disaster Recovery, assurez-vous que votre environnement répond aux exigences en matière de stockage ONTAP , de cluster VMware vCenter et de NetApp Console .
Versions du logiciel
| Composant | Version minimale |
|---|---|
Amazon FSx for NetApp ONTAP |
Dernière version disponible |
Google Cloud VMware Engine utilisant Google Cloud NetApp Volumes |
Dernière version disponible |
Logiciel ONTAP |
ONTAP 9.10.0 ou version ultérieure |
VMware Cloud pour AWS |
Dernière version disponible |
VMware sur site vCenter |
7.0u3 ou version ultérieure |
Prérequis et considérations relatifs à Google Cloud
Lors de la reprise après sinistre sur Google Cloud VMware Engine utilisant Google Cloud NetApp Volumes, assurez-vous de configurer les autorisations appropriées et de respecter les considérations mentionnées.
-
Contactez l'équipe SRE de Google pour ajouter à la liste blanche :
-
API de synchronisation pour transférer les instantanés du stockage sur site vers Google Cloud NetApp Volumes.
-
le projet Google avec le moteur VMware pour la création, le montage et le démontage de banques de données.
-
-
Vous devez"Déposez une demande pour ajouter vos volumes à la liste blanche en matière de réplication hybride." .
-
Soyez conscient de"Quotas et limites de Google Cloud NetApp Volumes" .
-
Vous ne pouvez ajouter qu'un seul volume ou une seule banque de données à un plan de réplication.
-
Examiner"limites" .
Considérations relatives au basculement
-
Le basculement n'est pris en charge qu'avec la dernière version instantanée. Si nécessaire, vous pouvez créer un nouvel instantané pendant la prise de cliché (c'est-à-dire que l'option d'instantané sélectif doit être désactivée).
-
Il est impossible de créer un nouvel instantané après un basculement.
-
Il est impossible de conserver et de réconcilier les instantanés après un basculement.
Considérations relatives aux solutions de repli
-
La restauration n'est possible qu'avec l'option de capture d'écran sélective. Il est impossible d'effectuer une restauration en prenant un nouvel instantané.
-
Si vous supprimez le peering de cluster entre le stockage sur site et les clusters de stockage Google Cloud NetApp Volumes , vous devez supprimer manuellement l'entrée de peering de cluster et de machine virtuelle de stockage du cluster sur site. Pour plus d'informations, voir "Supprimer une relation d'homologue vserver".
Autorisations Google Cloud
Le principal de service dans Google Cloud doit se voir attribuer les rôles suivants ou des autorisations équivalentes :
Autorisations de la NetApp Console
L'utilisateur de la NetApp Console doit posséder les rôles suivants :
Prérequis de stockage ONTAP
Ces conditions préalables s'appliquent aux instances ONTAP ou Amazon FSX pour NetApp ONTAP .
-
Les clusters source et de destination doivent avoir une relation d'homologue.
-
La SVM qui héberge les volumes de reprise après sinistre doit exister sur le cluster de destination.
-
La SVM source et la SVM de destination doivent avoir une relation homologue.
-
En cas de déploiement avec Amazon FSx for NetApp ONTAP, la condition préalable suivante s'applique :
-
Une instance Amazon FSx for NetApp ONTAP pour héberger les magasins de données VMware DR doit exister dans votre VPC. Pour commencer, voir"la documentation Amazon FSx pour ONTAP" .
-
Conditions préalables pour les clusters VMware vCenter
Ces conditions préalables s’appliquent à la fois aux clusters vCenter sur site et au centre de données défini par logiciel (SDDC) VMware Cloud for AWS.
-
Revoir"privilèges vCenter" requis pour la NetApp Disaster Recovery.
-
Tous les clusters VMware que vous souhaitez que NetApp Disaster Recovery gère utilisent les volumes ONTAP pour héberger toutes les machines virtuelles que vous souhaitez protéger.
-
Toutes les banques de données VMware à gérer par NetApp Disaster Recovery doivent utiliser l'un des protocoles suivants :
-
NFS
-
VMFS utilisant le protocole iSCSI ou FC
-
-
VMware vSphere version 7.0 Update 3 (7.0v3) ou ultérieure
-
Si vous utilisez VMware Cloud SDDC, ces conditions préalables s'appliquent.
-
Dans la console VMware Cloud, utilisez les rôles de service Administrateur et Administrateur NSX Cloud. Utilisez également le propriétaire de l’organisation pour le rôle Organisation. Se référer à "Utilisation de VMware Cloud Foundations avec la documentation AWS FSx pour NetApp ONTAP" .
-
Liez le SDDC VMware Cloud à l’instance Amazon FSx for NetApp ONTAP . Se référer à "Informations sur le déploiement de l'intégration de VMware Cloud sur AWS avec Amazon FSx for NetApp ONTAP" .
-
Prérequis de la NetApp Console
Démarrer avec la NetApp Console
Si vous ne l'avez pas déjà fait, "inscrivez-vous à la NetApp Console et créez une organisation" .
Collecter les informations d'identification pour ONTAP et VMware
-
Les informations d'identification Amazon FSx for ONTAP et AWS doivent être ajoutées au système dans le cadre du projet NetApp Console qui gère la NetApp Disaster Recovery.
-
NetApp Disaster Recovery nécessite des informations d’identification vCenter. Vous entrez les informations d'identification vCenter lorsque vous ajoutez un site dans NetApp Disaster Recovery.
Pour obtenir la liste des privilèges vCenter nécessaires, reportez-vous à"Privilèges vCenter nécessaires pour la NetApp Disaster Recovery" . Pour obtenir des instructions sur la façon d'ajouter un site, reportez-vous à"Ajouter un site" .
Créer l'agent de la NetApp Console
L'agent de console est un composant logiciel qui permet à la console de communiquer avec votre stockage ONTAP et vos clusters VMware vCenter. Il est nécessaire au bon fonctionnement de la reprise après sinistre. L'agent réside dans votre réseau privé (un centre de données sur site ou un VPC cloud) et communique avec vos instances de stockage ONTAP et tous les composants serveur et application supplémentaires. Pour la reprise après sinistre, il s’agit d’un accès à vos clusters vCenter gérés.
Un agent de console doit être configuré dans la NetApp Console. Lorsque vous utilisez l’agent, il inclura les fonctionnalités appropriées pour le service de reprise après sinistre.
-
NetApp Disaster Recovery fonctionne uniquement avec le déploiement d’agent en mode standard. Voir "Prise en main de la NetApp Console en mode standard" .
-
Assurez-vous que les vCenters source et de destination utilisent le même agent de console.
-
Type d'agent de console requis :
-
Reprise après sinistre sur site vers sur site : installez l’agent de la console sur site sur le site de reprise après sinistre. En utilisant cette méthode, une défaillance du site principal n’empêche pas le service de redémarrer vos ressources virtuelles sur le site DR. Se référer à "Installer et configurer l'agent de console sur site" .
-
Sur site sur AWS : installez l’agent de console pour AWS dans votre AWS VPC. Se référer à "Options d'installation de l'agent de console dans AWS" .
Pour les connexions sur site vers sur site, utilisez l’agent de console sur site. Pour les connexions sur site vers AWS, utilisez l'agent de la console AWS, qui a accès au vCenter sur site source et au vCenter sur site de destination. -
L'agent Console installé doit pouvoir accéder à toutes les instances de cluster VMware vCenter et aux hôtes ESXi gérés par ces clusters vCenter que la reprise après sinistre gérera.
-
-
Toutes les baies ONTAP à gérer par NetApp Disaster Recovery doivent être ajoutées à tout système du projet NetApp Console qui sera utilisé pour gérer NetApp Disaster Recovery.
-
Pour plus d'informations sur la configuration d'un proxy intelligent pour NetApp Disaster Recovery, consultez"Configurez votre infrastructure pour la NetApp Disaster Recovery" .
Prérequis de charge de travail
Pour garantir la réussite des processus de cohérence des applications, appliquez ces conditions préalables :
-
Assurez-vous que les outils VMware (ou les outils Open VM) sont en cours d’exécution sur les machines virtuelles qui seront protégées.
-
Pour les machines virtuelles Windows exécutant Microsoft SQL Server, Oracle Database ou les deux, les bases de données doivent avoir leurs rédacteurs VSS activés.
-
Les bases de données Oracle exécutées sur un système d'exploitation Linux doivent avoir l'authentification utilisateur du système d'exploitation activée pour le rôle SYSDBA de la base de données Oracle.