Inversion du sens de réplication

Il est possible d'inverser le sens de réplication pour prendre en charge les plans de récupération après sinistre classiques à deux systèmes. Cette opération est semblable à l'opération de dissociation décrite ci-dessus, mais configure en outre une action de réplication sur le nouveau projet local pour la réplication incrémentielle sur le système source. Aucune modification n'est apportée sur le système source au terme de cette opération. Toutefois, la première tentative de mise à jour utilisant cette action 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.

Cette fonction ne redirige pas automatiquement les charges de travail de production, ne basculent pas les adresses IP ou n'exécute pas d'autres activités liées au basculement en cas de récupération après sinistre en plus de modifier le statut lecture/écriture des copies de données principales et secondaires.

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 ZFSSA à un autre, l'inversion de cette réplication sur le ZFSSA cible supprime le calendrier de réplication. Une action de réplication est ensuite créée au niveau projet, qui comprend le ZFSSA cible correct sans calendrier.

Comme indiqué ci-dessus, cette fonction permet généralement d'implémenter une configuration de récupération après sinistre à deux systèmes dans laquelle un système principal se charge des données de production et les réplique vers un système secondaire ou DR (le plus souvent dans un autre centre de données) prêt à se charger du trafic de production dans le cas d'un sinistre sur le site principal. Dans le cas d'un sinistre sur le site principal, la copie du site secondaire doit être configurée comme "principale" en lui conférant la propriété inscriptible et en redirigeant le trafic de production vers le site secondaire. Lorsque le site principal sera réparé, les modifications qui se seront succédé sur le site secondaire pourront être répliquées vers le site principal et ce dernier pourra reprendre la charge de travail de production.

La séquence type des événements dans un tel plan est la suivante :

• Le système principal assume la charge de travail de production et assure la réplication vers le système secondaire.

• Un sinistre se produit, avec pour conséquence possible une panne totale du système sur le site principal. Les administrateurs inversent le sens de la réplication sur le site secondaire, en exportant les partages répliqués dans un nouveau projet configuré pour la réplication vers le site principal lorsque ce dernier est restauré. Entre-temps, la charge de travail de production est redirigée vers le site secondaire.

• Lorsque le site principal est à nouveau en ligne, un administrateur lance une mise à jour de réplication depuis le site secondaire vers le site principal. Cette opération convertit la copie de site principal dans un package de réplication, annulant toute modification effectuée depuis la dernière mise à jour réussie sur la cible (avant la panne). Une fois la copie du site principal à jour, le sens de la réplication est à nouveau inversé par l'administrateur, rendant la copie inscriptible sur le site principal. Le trafic de production est redirigé vers le site principal. La réplication reprend à partir du site principal vers le site secondaire, restaurant ainsi la relation initiale entre les copies principale et secondaire.

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 ZFSSA cible (qui est maintenant le ZFSSA source).

Pour inverser la réplication dans la BUI, accédez au package de réplication (voir ci-dessus) et cliquez sur l'onglet Réplication, puis sur le bouton . La boîte de dialogue qui s'affiche alors permet à l'administrateur d'indiquer le nom du nouveau projet local.

Pour inverser la réplication dans la CLI, accédez au package de réplication (voir ci-dessus) et exécutez la commande reverse. Cette commande sélectionne un argument facultatif indiquant le nom du nouveau projet local. Si aucun argument n'est indiqué, le nom d'origine est utilisé.

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 (voir ci-dessus). 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 DR.