Dans les articles précédents, nous avions vu comment procéder à l’installation d’un environnement CCR et SCR, ainsi que les commandes à connaître pour leurs administrations quotidiennes.
Dans cet article, nous allons détailler le fonctionnement interne de la technologie SCR basée sur la réplication de journaux et ferons quelques rapprochements avec la technologie CCR qui utilise de façon quelque peu différente les mêmes mécanismes. De la sorte, vous serez mieux à même de comprendre les comportements des processus impliqués dans cet environnement de secours que constitue l’environnement SCR.
La réplication des bases de données est basée sur la génération des journaux par chaque base de données et la recopie de ces derniers vers le serveur passif (
CCR) ou serveur cible (
SCR). Chaque journal séquentiel est généré par l’activité des utilisateurs et possède une taille fixe de
1 MB contrairement à ceux de
Microsoft Exchange 2003 (5 Mega).
Ces journaux sont également utilisés pour la sauvegarde et les opérations de restauration. Dans le cas du d’une réplication continue quelle soit de type SCR ou CCR, ces journaux sont utilisés pour la mise à jour de façon asynchrone et continue d’une ou plusieurs bases de données. Cette réplication est par conséquent effectuée par la copie des journaux et le fait de rejouer ces derniers sur la base de secours. Dans un environnement CCR ou SCR, une base de données doit correspondre à un seul groupe de stockage et réciproquement. Pour des raisons de maintenance ou d’arrêt de serveur la réplication peut être amenée à être stoppée.
Deux services sont à l’origine de cette réplication.
- Microsoft Exchange Information Store
- Microsoft Exchange Réplication Service
Le premier, relativement connu des administrateurs Exchange 2003/ 2007 est entre autres, responsable de l’exécution des requêtes utilisateurs, il génère par conséquent les journaux et met à jours les bases de données via le moteur ESE. Le second service impliqué dans la réplication continue, est Microsoft Exchange Replication Service qui lui assure la copie des journaux et le fait de rejouer ces derniers sur les bases ainsi dupliquées. Ce dernier est dé – pen dant du service Active Directory Topology et peut être stoppé ou arrêté soit en ligne de commande soit par l’interface graphique.
Téléchargez cette ressource
État des lieux de la sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
