Le nombre de CPU virtuels

La quantité de DRAM virtuelle

La configuration de l'adresse IP

La possibilité d'exécuter des scripts shell du système d'exploitation invité dans le cadre du processus de basculement

La possibilité de modifier les noms des machines virtuelles ayant échoué en utilisant un préfixe et un suffixe uniques

La possibilité de définir l'ordre de redémarrage lors du basculement de la machine virtuelle

Option Utiliser les mêmes paramètres de masque de sous-réseau, DNS et de passerelle : Étant donné que ces paramètres sont généralement les mêmes pour toutes les machines virtuelles connectées aux mêmes réseaux virtuels, il peut être plus simple de les configurer une seule fois et de laisser Disaster Recovery utiliser les paramètres pour toutes les machines virtuelles du groupe de ressources protégé par le plan de réplication. Si certaines machines virtuelles utilisent des paramètres différents, vous devez décocher cette case et fournir ces paramètres pour chaque machine virtuelle.

Type d'adresse IP : Reconfigurez la configuration de la VM pour qu'elle corresponde aux exigences du réseau virtuel cible. La reprise après sinistre propose deux options : DHCP ou adresse IP statique. Pour les adresses IP statiques, configurez le masque de sous-réseau, la passerelle et les serveurs DNS. Saisissez également les identifiants des VM.

Scripts : Vous pouvez inclure des scripts personnalisés hébergés par le système d’exploitation invité au format .sh, .bat ou .ps1 en tant que post-processus. Grâce aux scripts personnalisés, la reprise après sinistre peut exécuter votre script après un basculement, un retour en arrière et une migration de processus. Par exemple, vous pouvez utiliser un script personnalisé pour reprendre toutes les transactions de la base de données une fois le basculement terminé. Ce service peut exécuter des scripts au sein de machines virtuelles fonctionnant sous Microsoft Windows ou toute variante Linux prise en charge avec des paramètres de ligne de commande. Vous pouvez attribuer un script à des machines virtuelles individuelles ou à toutes les machines virtuelles du plan de réplication.

Rétrograder la version matérielle de la VM et l'enregistrer : Sélectionnez cette option si la version de l'hôte ESX de destination est antérieure à celle de la source afin qu'elles correspondent lors de l'enregistrement.

Conserver la hiérarchie des dossiers d'origine : Par défaut, la reprise après sinistre conserve la hiérarchie de l'inventaire des machines virtuelles (structure des dossiers) en cas de basculement. Si le répertoire cible de récupération ne possède pas l'arborescence de dossiers d'origine, la fonction de récupération après sinistre la crée.

Préfixe et suffixe de la VM cible : Dans les détails de la VM, vous pouvez éventuellement ajouter un préfixe et un suffixe à chaque nom de VM basculée. Cela peut être utile pour différencier les VM basculées des VM de production exécutées sur le même cluster vCenter. Par exemple, vous pouvez ajouter le préfixe « DR- » et le suffixe « -failover » au nom de la VM. Certaines personnes ajoutent un deuxième vCenter de production pour héberger temporairement des VM sur un autre site en cas de sinistre. L’ajout d’un préfixe ou d’un suffixe peut vous aider à identifier rapidement les VM basculées. Vous pouvez également utiliser le préfixe ou le suffixe dans des scripts personnalisés.

CPU et Mémoire (Go) : Dans les détails de la VM, vous pouvez éventuellement redimensionner le CPU et la mémoire de la VM.

Vous pouvez configurer la DRAM en gigaoctets (Gio) ou en mégaoctets (Mio). Bien que chaque machine virtuelle nécessite au moins un Mio de RAM, la quantité réelle doit garantir que le système d'exploitation invité de la machine virtuelle et toutes les applications en cours d'exécution peuvent fonctionner efficacement.

Ordre de démarrage : vous pouvez modifier l’ordre de démarrage après un basculement pour toutes les machines virtuelles sélectionnées dans les groupes de ressources. Par défaut, toutes les machines virtuelles démarrent ensemble en parallèle ; toutefois, vous pouvez apporter des modifications à cette étape. Cela permet de garantir que toutes vos machines virtuelles de priorité 1 sont en cours d’exécution avant le démarrage des machines virtuelles des priorités suivantes.

Délai de démarrage : ajustez le délai en minutes de l'action de démarrage, indiquant la durée pendant laquelle la machine virtuelle attendra avant de démarrer le processus de mise sous tension. Entrez une valeur comprise entre 0 et 10 minutes.

Cohérent au niveau des applications : Indiquez s'il faut créer des copies d'instantané cohérentes au niveau des applications. Le service mettra l'application en veille, puis prendra un instantané pour obtenir un état cohérent de l'application. Cette fonctionnalité est prise en charge avec Oracle exécuté sous Windows et Linux et SQL Server exécuté sous Windows. Voir plus de détails ci-dessous.

Utiliser les sauvegardes et les calendriers de conservation gérés par la plateforme : si vous utilisez une solution externe de gestion des snapshots, cochez cette case. La reprise après sinistre prend en charge l’utilisation de solutions externes de gestion des snapshots, telles que le planificateur de stratégie natif ONTAP SnapMirror ou les intégrations tierces. Si chaque banque de données (volume) du plan de réplication a déjà une relation SnapMirror gérée ailleurs, vous pouvez utiliser ces snapshots comme points de restauration dans la reprise après sinistre.

Heure de début des sauvegardes et de la conservation : Saisissez la date et l’heure auxquelles vous souhaitez que les sauvegardes et la conservation commencent à s’exécuter.

Fréquence des sauvegardes et de leur conservation : Indiquez l’intervalle de temps en heures et minutes. Par exemple, si vous indiquez 1 heure, le service prendra un snapshot chaque heure.

Retention count for all datastores : Saisissez le nombre de snapshots que vous souhaitez conserver.

Le nombre d'instantanés conservés ainsi que le taux de modification des données entre chaque instantané déterminent la quantité d'espace de stockage consommée sur la source et la destination. Plus vous conservez d'instantanés, plus l'espace de stockage consommé est important.

Magasins de données source et cible : Si plusieurs relations SnapMirror (de distribution) existent, vous pouvez sélectionner la destination à utiliser. Si une relation SnapMirror est déjà établie pour un volume, les magasins de données source et cible correspondants s’affichent. Si un volume n’a pas de relation SnapMirror, vous pouvez en créer une maintenant en sélectionnant un cluster de destination, une SVM de destination et en indiquant un nom de volume. Le service créera le volume et la relation SnapMirror.

Si vous souhaitez créer une relation SnapMirror dans ce service, le cluster et le peering de sa SVM doivent déjà avoir été configurés en dehors de la reprise après sinistre.