Réplication locale en continu (LCR)

ou à assumer la responsabilité de l’achat et de la maintenance de systèmes en cluster. Pour répondre à cette attente, Microsoft a introduit la réplication locale en continu (LCR). Lorsque vous l’activez pour un groupe de stockage (SG), Exchange commence par copier la base du groupe vers un volume distinct sur le même serveur (processus appelé amorçage [seeding]). Ensuite l’ensemble de journaux des transactions est également copié. Une fois la copie initiale terminée, la base de données est dite en mode relecture (replay), et chaque nouvelle génération des journaux des transactions est copiée, dès sa fermeture, sur le volume de sauvegarde. En d’autres termes, lorsque Exchange ouvre un nouveau fichier journal, il copie immédiatement le précédent fichier journal ouvert sur le volume cible LCR. En cas de défaillance, vous pouvez rapidement passer sur la copie de sauvegarde, soit en modifiant les chemins du fichier journal et de la base de données au niveau du groupe de stockage, soit en copiant la base de données de son emplacement de sauvegarde vers son emplacement d’origine.

La réplication LCR permet d’accomplir trois tâches :

• Elle assure l’envoi des journaux des transactions et leur relecture afin d’accélérer la reprise en cas de défaillance de la base de données.

• Elle réduit la nécessité d’effectuer des sauvegardes complètes fréquentes ; les sauvegardes complètes régulières restent nécessaires, mais la réplication LCR peut devenir votre moyen de reprise principal après une défaillance.

• Elle vous permet de sauvegarder, de tester ou de répliquer la copie de la base de données au lieu de la base de données principale. Vous pouvez, par exemple, sauvegarder la copie LCR sans affecter les performances de la base de données principale, du fait du positionnement de la copie de sauvegarde sur un volume distinct.

La réplication LCR se déroule sur un seul serveur et ne peut pas servir à copier des données d’un serveur physique vers un autre. Par conséquent, vous allez peut-être chercher à comparer cette approche avec la mise en miroir de disque, laquelle est bien souvent la méthode de prédilection pour conserver une copie de sauvegarde actualisée en permanence des données sur un seul serveur. La mise en miroir de disque est sans nul doute utile car elle assure une protection au niveau matériel. Néanmoins, Exchange ne reconnaît pas cette fonction et l’inverse est aussi vrai. Par conséquent, le mode de surveillance et de gestion des volumes en miroir n’a rien à voir avec la gestion des données stockées sur les volumes. Cette absence de reconnaissance par Exchange signifie également que les défaillances matérielles sont transparentes pour votre serveur de messagerie, ce qui constitue un point essentiel en faveur de la mise en miroir de disque. Elle présente toutefois l’inconvénient d’empêcher une utilisation indépendante de la copie en miroir du volume; celle-ci doit demeurer synchronisée avec l’original.

La réplication LCR modifie la situation en transformant la copie de sauvegarde de la base de données en objet visible dans le système de fichiers, d’où la possibilité de le copier, de le déplacer ou de le tester si nécessaire. De même, la mise en miroir de disque copie sans distinction tous les éléments corrompus de la source du miroir vers la sauvegarde. De son côté, la réplication LCR est basée sur les transactions, de sorte que les corruptions physiques ou de bas niveau introduites par des éléments tels que des pilotes bogués ne sont pas répliquées.

La réplication LCR comporte toutefois des limitations. Premièrement, vous ne pouvez protéger qu’une seule base de données par groupe de stockage. Pour en protéger plusieurs, il faut les placer dans leurs propres groupes de stockage, mais cette restriction n’est pas contraignante car Exchange 2007 Enterprise Edition gère jusqu’à 50 groupes de stockage. Néanmoins, l’ajout de groupes de stockage peut se traduire par des changements sur l’emplacement et le mode de stockage et de gestion des fichiers journaux des transactions. Deuxièmement, si vous utilisez la réplication LCR pour protéger une base de données de dossiers publics, aucun autre serveur de l’organisation ne pourra contenir une réplique des dossiers de la base de données en question. Cette restriction n’est pas non plus importante car les dossiers publics comportent déjà un niveau élevé de protection, grâce à la réplication sur plusieurs maîtres.