Go to main content
Guide d'administration des systèmes Oracle® ZFS Storage Appliance, version OS8.7.0

Quitter la vue de l'impression

Mis à jour : Mars 2017
 
 

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 à 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 33  Réplication distante pour la récupération après sinistre

image:Figure montrant les étapes de la réplication inversée pour la récupération après sinistre.

Légende
Description
1
Le système de production correspond à l'appareil source qui sert la charge de travail du client et réplique vers la cible de réplication située sur le site de récupération.
Une défaillance complète de l'appareil source se produit sur le site de production.
Depuis le site de récupération, l'administrateur inverses le sens de la réplication. Cette opération convertit le package de réplication en projet local et accessible en écriture.
L'administrateur redirige les charges de travail du client et bascule les adresses IP vers le site de récupération.
2
Une fois le site de production en mesure de reprendre son activité normale, l'administrateur lance une mise à jour de réplication du site de récupération au site de production.
Cette opération convertit la copie de production en package de réplication et restaure l'ensemble des modifications écrites dans le site de récupération pendant que le site de production était en panne.
3
Une fois le site de production mis à jour, le sens de la réplication est à nouveau inversé par l'administrateur, rendant la copie accessible en écriture sur le site de production.
L'administrateur redirige ensuite les charges de travail du client et bascule les adresses IP vers le site de production.
La relation initiale entre l'appareil source sur le site de production et la cible de réplication sur le site de récupération est rétablie.

Inversion de niveau partage et de niveau projet

Lors de la conversion du projet source d'origine en package de réplication sur l'appareil 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é.

Avant d'inverser le sens de réplication d'un package, arrêtez les mises à jour de réplication de ce projet à partir de l'appareil 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 la précédente cible de réplication (qui est maintenant l'appareil source).

Si une mise à jour de réplication est effectuée pendant ou après une opération d'inversion, la mise à jour échoue avec une alerte appropriée. L'action de réplication est ensuite désactivée, empêchant ainsi toute mise à jour ultérieure à partir de cette action sur la cible de réplication. Une nouvelle action de réplication et une mise à jour complète sont requises pour envoyer des mises à jour du projet d'origine vers un nouveau package de réplication.

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