Réplication continue en cluster (CCR)

détenir une ressource spécifique à un instant donné. Cela signifie que votre implémentation du cluster a besoin d’un matériel de stockage partagé, lequel a souvent tendance à être onéreux et peu commode. En particulier, l’extension de votre cluster sur un réseau étendu (WAN) peut présenter des difficultés en raison de la latence d’écriture introduite par la réplication synchrone, qui est le seul type de réplication pris en charge par Microsoft.

La réplication CCR élimine cet aspect matériel en permettant de créer des clusters avec réplication automatique des données du noeud actif sur un noeud passif, sans matériel ni composants de stockage partagés. Cette approche vous prémunit contre la défaillance d’un seul serveur, tout comme les clusters à copie unique traditionnels. Toutefois, elle assure aussi la protection contre les défaillances de sites ou de centres de calcul car il n’est pas nécessaire aux deux noeuds du cluster CCR de résider au même endroit (à condition qu’ils se trouvent sur le même sous-réseau IP, comme indiqué précédemment). Petit cadeau supplémentaire, il n’est pas nécessaire d’employer un matériel identique pour les noeuds d’un cluster CCR ; en fait, vous pouvez même avoir des noeuds qui ne figurent pas sur la liste de compatibilité du matériel, même si Microsoft déconseille cette approche. Les clusters CCR n’ont pas besoin d’un SAN, mais lorsque vous commencez à ajouter des quantités de stockage DAS importantes à vos noeuds, la tâche ainsi que les frais de gestion et de maintenance peuvent devenir prohibitifs.

Mais le plus important est qu’une implémentation de réplication CCR appropriée ne présente aucun point unique de défaillance. Il s’agit d’une amélioration majeure par rapport aux clusters Exchange 2003, lesquels comportent au moins un point de défaillance potentiel : le volume de quorum partagé. Pour procurer cet avantage, la réplication CCR a besoin d’une fonction de clustering Windows, intitulée clusters à jeu de noeud majoritaire. Avec cette approche, la ressource quorum employée par le cluster SCC est associée à un témoin de partage de fichiers. Il s’agit, pour l’essentiel, d’un partage de fichiers CIFS (Common Internet File System) qui est utilisable comme ressource quorum mais n’a pas besoin d’être détenu physiquement par l’un des noeuds du cluster. L’implémentation d’un témoin de partage de fichiers sur votre cluster nécessite Windows Server 2003 Release 2 ou Windows Server 2003 Service Pack 1 avec un correctif.

Avec la réplication CCR, le sous-système de clustering Windows sous-jacent continue d’assurer la détection des défaillances, le basculement et la restauration automatique ; la réplication CCR protège les données Exchange avant une défaillance et met à disposition une réplique pendant le basculement. D’un point de vue opérationnel, la réplication CCR fonctionne largement comme la réplication LCR : vous créez un cluster, puis un groupe de stockage, et vous demandez à Exchange d’activer la réplication CCR pour ce dernier. A ce stade, la base de données est amorcée et les fichiers journaux sont copiés. Toutefois, la méthode de transport employée pour les fichiers journaux diffère quelque peu. Avec la réplication LCR, les journaux sont copiés d’un disque vers un autre, alors qu’avec la réplication CCR, le noeud passif récupère (« pull ») les journaux sur le noeud actif via un partage de fichiers.

La méthode de transport de la réplication CCR réduit ainsi la charge sur le noeud actif car le noeud passif se charge de la récupération des fichiers journaux. Autre différence, chaque fichier journal est relu sur la copie passive de la base de données dès son arrivée. Cela réduit les délais de basculement en diminuant les risques d’une relecture prolongée d’un fichier journal lorsque la copie CCR est montée dans le cadre d’un processus de basculement. En cas de défaillance, le noeud passif devient automatiquement actif et la copie des données protégées par la réplication CCR est activée. La réplication relit tous les fichiers de transactions répliqués avec succès, de sorte que le volume des données perdues est généralement limité à celles du dernier fichier journal ouvert.

La réplication CCR présente les mêmes limitations que la réplication LCR : une seule base de données peut être répliquée par groupe de stockage, et il est impossible de combiner la réplication des dossiers publics et la réplication CCR. D’autre part, vous devez créer et gérer un témoin de partage de fichiers pour le cluster CCR ; cette opération n’est pas complexe, mais nécessite du travail de planification. Par ailleurs, si vous utilisez les clusters Exchange 2003 ou Exchange 2000, ayez à l’esprit que Microsoft ne gère pas les mises à niveau sur place (in-place). Par conséquent, il faut déplacer les boîtes aux lettres du cluster existant vers un autre serveur, effectuer la mise à niveau, puis rapatrier les boîtes aux lettres sur le nouveau cluster.

La réplication CCR signifie, pour l’essentiel, que Microsoft fournit une solution de réplication des données parfaitement supportée dans le cadre d’Exchange 2007. Elle n’offre pas la même souplesse que de nombreux outils de réplication d’autres éditeurs, mais elle peut réduire le besoin d’investissements supplémentaires pour réaliser vos objectifs de haute disponibilité.