Fonctionnement de la réplication inversée
Il est possible d'inverser le sens de réplication pour prendre en charge les plans de récupération après sinistre à deux systèmes et les sauvegardes disque à disque.
Inversion de la réplication pour une récupération après sinistre
L'opération de réplication inversée convertit le package de réplication en un projet local. Cette opération configure également une action de réplication sur le nouveau projet local permettant la réplication incrémentielle vers l'appareil source. La première tentative de mise à jour convertit le projet d'origine sur le système source en package de réplication et annule toute modification effectuée depuis la dernière mise à jour de réplication réussie sur ce système.
La figure suivante décrit une séquence standard de réplication inversée.
Figure 36 Réplication distante pour la récupération après sinistre
|
Dans le cadre de la conversion du projet source d'origine en package de réplication sur le système source d'origine (faisant désormais office de cible), les partages répliqués en tant que paire action/package en cours d'inversion sont déplacées dans un nouveau package de réplication et leur exportation est annulée. Le projet d'origine reste dans la collection, locale mais peut se retrouver vide si la paire action/package contenait tous ses partages. Lorsque la réplication de niveau partage est inversée, aucun autre partage du projet d'origine n'est modifié.
Après avoir établi la réplication de niveau partage d'un appareil à un autre, l'inversion de cette réplication sur l'appareil cible supprime le calendrier de réplication. Une action de réplication est ensuite créée au niveau projet, qui comprend l'appareil cible correct sans calendrier.
Lors de l'inversion du sens de réplication pour un package, il est vivement recommandé aux administrateurs de commencer par arrêter la réplication de ce projet à partir de la source. Si une mise à jour de réplication est en cours lorsqu'un administrateur inverse le sens de réplication d'un projet, les administrateurs ne peuvent pas savoir quel instantané de réplication cohérent a été utilisé pour créer le projet qui en résulte sur le précédent appareil cible (qui est maintenant l'appareil source).
Tous les partages locaux étant exportés, tous les partages d'un package sont exportés lorsque celui-ci est inversé, qu'ils l'aient déjà été ou non. S'il existe des conflits de point de montage entre les systèmes de fichiers répliqués et les autres systèmes de fichiers, l'opération d'inversion échoue. Il faut résoudre ces conflits avant l'inversion en reconfigurant les points de montage des partages concernés. Cette opération faisant généralement partie du chemin critique de restauration du service de production, il est vivement recommandé de résoudre ces conflits de point de montage lors de la configuration initiale du système plutôt que lors du basculement de récupération après sinistre.
Rubriques connexes