Réplication continue en cluster

  • Article

 

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2008-03-21

La réplication continue en cluster (CCR) est une fonctionnalité de haute disponibilité élevée de Microsoft Exchange Server 2007 qui combine les technologies d'envoi des journaux asynchrone et de relecture intégrées dans Exchange 2007 avec les fonctionnalités de gestion et de basculement du service de cluster.

La fonction CCR vise à assurer une disponibilité élevée pour les serveurs de boîtes aux lettres Exchange 2007 en fournissant une solution qui :

  • n'a aucun point de défaillance ;

  • n'a aucune configuration matérielle requise particulière ;

  • n'a aucune configuration requise de stockage partagé ;

  • peut être déployée dans une ou deux configurations de centre de données ;

  • peut réduire la fréquence de sauvegarde complète, le volume total de données sauvegardées et le temps de récupération du contrat SLA depuis la première défaillance.

La CCR utilise la fonctionnalité de récupération après une défaillance de base de données dans Exchange 2007 pour activer la mise à jour asynchrone et en continu d'une seconde copie d'une base de données avec les modifications apportées à la copie active de la base de données. Lors de l'installation du noeud passif dans un environnement CCR, chaque groupe de stockage et sa base de données sont copiés du noeud actif vers le noeud passif. Cette opération se nomme amorçage et fournit une ligne de base de la base de données pour la réplication. Une fois l'amorçage initial effectué, la copie et la relecture du journal sont réalisées en continu.

Dans un environnement CCR, les possibilités de réplication sont intégrées avec le service de cluster pour fournir une solution de disponibilité élevée. Outre l'offre de la disponibilité des services et des données, la CCR prévoit également des interruptions programmées. Lorsque les mises à jour doivent être installées ou lorsque la maintenance doit être effectuée, un administrateur peut déplacer manuellement un serveur de boîtes aux lettres en cluster (nommé serveur virtuel Exchange dans les versions précédentes d'Exchange Server) vers un noeud passif. Une fois le déplacement effectué, l'administrateur peut effectuer la maintenance nécessaire.

Le déplacement est effectué à l'aide de la cmdlet Move-ClusteredMailboxServer dans l'environnement de ligne de commande Exchange Management Shell. Microsoft Exchange Server 2007 Service Pack 1 inclut également un nouvel Assistant Gestion de serveur de boîtes aux lettres en cluster dans la console de gestion Exchange pour déplacer des serveurs de boîtes aux lettres en cluster. La logique de ces tâches effectue l'application nécessaire pour garantir qu'aucune donnée de boîte aux lettres n'est perdue lors du déplacement. Les tâches effectuent également des vérifications avant le déplacement pour garantir que la réplication sur le noeud passif peut être rapidement activée.

Les éléments clés sur la CCR sont les suivants :

  • La réplication continue est asynchrone   Les journaux ne sont pas copiés tant qu'ils ne sont pas clôturés et plus utilisés par le serveur de boîtes aux lettres. Cela signifie que le noeud passif ne dispose généralement pas de copie de chaque fichier journal existant sur le noeud actif. Il existe une exception : lorsque l'administrateur a initié une interruption programmée sur le noeud actif pour appliquer une mise à jour ou effectuer une autre maintenance.

  • La réplication continue ne place aucun processeur et aucune charge d'E/S sur le noeud actif lors d'une opération normale   La CCR utilise le noeud passif pour copier et relire les journaux. Les journaux sont accessibles depuis le noeud passif via un partage de fichiers sécurisé.

  • Les modifications du noeud actif et passif sur la durée de vie du cluster sont automatiquement désignées   Par exemple, après un basculement, la désignation actif et passif s'inverse. Cela signifie que le sens de la réplication s'inverse. Aucune action d'administration n'est requise pour inverser la réplication. Le système gère automatiquement l'inversion de la réplication.

  • Le basculement et les interruptions programmées sont symétriques en fonctions et en performances   Par exemple, la durée de basculement est la même pour passer du Noeud1 au Noeud2 et du Noeud2 au Noeud1. En général, cela ne dépasse pas deux minutes. Sur des serveurs plus importants, les interruptions programmées durent généralement moins de quatre minutes. La différence de durée entre un basculement et les interruptions programmées est associée à la durée nécessaire à la réalisation d'un arrêt contrôlé du noeud actif sur une interruption programmée. Cette différence de performances peut être réduite dans un pack d'administration ultérieur.

  • Les sauvegardes du Service VSS sur le noeud passif sont prises en charge   Cela permet aux administrateurs de décharger les sauvegardes du noeud actif et de développer la fenêtre de sauvegarde. En outre, des besoins en performances n'obligent pas les configurations plus importantes à prendre en charge le service VSS matériel pour utiliser les sauvegardes VSS. La copie et la relecture du journal constituent la charge de travail du noeud passif et aucune de ces deux activités n'est restreinte en temps réel comme le serveur de boîtes aux lettres en cluster sur le noeud actif. Par exemple, le noeud actif doit répondre aux demandes client dans un temps limité. Une fenêtre de sauvegarde plus longue peut être utilisée car le noeud passif n'ayant aucune contrainte de réponse en temps réel, cela permet d'avoir des bases de données et des tailles de boîtes aux lettres plus importantes.

  • Le total des données d'un support de sauvegarde est réduit   La copie passive de la CCR fournit la première ligne de défense contre l'endommagement et la perte de données. Ainsi, une double défaillance est requise pour que les sauvegardes soient nécessaires. Il se peut que la récupération suite à la première défaillance dispose d'un contrat SLA court car aucune restauration n'est requise. La récupération suite à la deuxième défaillance peut disposer d'un contrat SLA plus long. Par conséquent, les sauvegardes peuvent être effectuées sur un cycle complet hebdomadaire avec une stratégie de sauvegarde incrémentielle quotidienne. Cela réduit le volume total des données devant être placées sur le support de sauvegarde.

  • La CCR peut être combinée à la réplication continue de secours (SCR)   La CCR peut être combinée à la SCR pour répliquer des groupes de stockage localement dans un centre de données principal (à l'aide de la CCR pour la haute disponibilité) et à distance dans un centre de données secondaire ou de sauvegarde (à l'aide de la SCR pour la résilience de site). Le centre de données secondaire pourrait contenir un noeud passif dans un cluster avec basculement qui héberge les cibles de SCR. Ce type de cluster est appelé cluster de secours parce qu’il ne contient aucun serveur de boîtes aux lettres en cluster mais peut être configuré rapidement avec un serveur de boîtes aux lettres en cluster de remplacement dans un scénario de récupération. En cas de défaillance ou de perte du centre de données principal, les cibles de SCR hébergées dans ce cluster de secours peuvent être rapidement activées.

Architecture principale de CCR

La CCR associe les éléments suivants :

  • Fonctionnalités de basculement et de virtualisation fournies par les clusters avec basculement Microsoft

  • un modèle de quorum de cluster de basculement majoritaire qui utilise un partage de fichiers comme témoin de l'activité de cluster ;

  • les fonctionnalités de réplication et de relecture du journal des transactions dans Exchange 2007 ;

  • une fonctionnalité de file d'attente de messages du serveur de transport Hub appelée conteneur de dépôt de transport.

Cluster de basculement Windows

Comme le montre la figure suivante, dans Exchange 2007 SP1, la CCR utilise deux ordinateurs (appelés nœuds) réunis dans un cluster de basculement unique exécutant soit Windows Server 2003 Service Pack 2 soit Windows Server 2008. Les noeuds du cluster avec basculement hébergent un seul serveur de boîtes aux lettres en cluster. Un nœud en train d'exécuter un serveur de boîtes aux lettres en cluster est appelé nœud actif, tandis qu'un nœud qui n'exécute pas de serveur de boîtes aux lettres en cluster, mais qui fait partie du cluster, et la cible pour une réplication continue, est appelé nœud passif. Comme résultat d'interruptions planifiées et gérées et non planifiées, la désignation d’un noeud comme passif ou actif changera plusieurs fois au cours de la durée de vie d’un cluster de basculement.

Déploiement de base de la réplication continue en cluster

Architecture de réplication continue en cluster

Le cluster avec basculement est créé à l'aide du service de cluster et d'un type spécifique de modèle de quorum de cluster :

Témoin de partage de fichiers

Les deux modèles précédents de quorum utilisent un partage de fichiers sur un ordinateur tiers comme témoin. Dans ces modèles de quorum, un partage de fichiers sur un troisième ordinateur est utilisé afin d’éviter toute occurrence de partition de réseau au sein du cluster, également appelée Split-Brain Syndrome. Ce problème se produit quand tous les réseaux désignés pour assurer les communications à l'intérieur du cluster échouent et que les noeuds ne peuvent pas échanger de signaux de pulsations. Ce syndrome est évité en exigeant toujours qu'une majorité des deux noeuds et le partage de fichiers soient disponibles et interagissent pour que le serveur de boîtes aux lettres en cluster soit opérationnel. Quand une majorité des ordinateurs communiquent, le cluster a un quorum. Le partage de fichiers pour le témoin de partage de fichiers peut être hébergé sur tout ordinateur exécutant Windows Server. Il n'est pas nécessaire que la version du système d’exploitation Windows Server hébergeant le fichier corresponde au système d’exploitation de l’environnement de CCR. Toutefois, il est recommandé d'héberger le partage de fichiers sur un serveur de transport Hub dans le site de service d'annuaire Active Directory contenant le serveur de boîtes aux lettres en cluster ; ceci permet en effet à l'administrateur de messagerie de garder le contrôle sur le partage de fichiers.

Notes

Le partage de fichiers utilisé par le témoin de partage de fichiers ne peut pas être hébergé dans un environnement DFS (Distributed File System).

Le témoin de partage de fichiers utilise un partage de fichiers sur un ordinateur externe au cluster pour agir en tant que témoin des activités des deux noeuds qui forment le cluster. Le témoin est utilisé par les deux noeuds pour savoir quel noeud du cluster est sous surveillance. Le tableau de référence est uniquement requis lorsque les deux noeuds ne peuvent pas communiquer entre eux. Prenez l'exemple d'un serveur de boîtes aux lettres en cluster à deux noeuds formé du Noeud1 et du Noeud2. Dans le cas présent, le Noeud1 peut prendre le contrôle du tableau de référence et est, par conséquent, capable de prendre le contrôle du cluster et de rétablir le serveur de boîtes aux lettres en cluster. Si le Noeud2 est opérationnel, mais qu'il ne peut pas communiquer avec le Noeud1, le Noeud2 tentera vainement de prendre le contrôle du tableau de référence. L'incapacité de prendre le contrôle du tableau de référence pour le Noeud2 signifie qu'il ne doit pas rétablir un serveur de boîtes aux lettres en cluster.

Lorsque les deux noeuds peuvent interagir, le tableau de référence n'est pas obligatoire et peut être en mode hors connexion. Toutefois, un échec immédiat d'un des deux noeuds empêche le serveur de boîtes aux lettres en cluster d'être en ligne si le témoin de partage de fichiers n'est pas disponible.

Le partage de fichiers ne contient aucun état supplémentaire que ceux précédemment décrits. Par conséquent, les deux noeuds s'échangent toutes les informations de configuration de cluster. Il est important de comprendre cela car si le Noeud1 est disponible mais pas le Noeud2, le Noeud2 ne peut être disponible que lorsqu'il communique avec le Noeud1, en dépit de sa communication avec le témoin de partage de fichiers.

La prise en charge du témoin de partage de fichiers fournit une vérification d'accès périodique du témoin de partage de fichiers. Si la vérification d'accès échoue, l'événement est généré. L'événement peut être détecté, collecté et analysé par le système de surveillance. Cela permet au personnel d'exploitation de corriger le problème, avant que celui-ci ne cause une interruption suite à un deuxième échec consécutif.

L'accès au partage de fichiers s'effectue dans les conditions suivantes :

  • quand un noeud de cluster devient actif et qu'un seul noeud de cluster est disponible ;

  • quand un problème de connexion réseau empêche un noeud précédemment accessible de communiquer avec le cluster ;

  • quand un noeud de cluster quitte le cluster ;

  • périodiquement à des fins de validation. La fréquence est configurable.

Ces raisons expliquent pourquoi la charge sur le partage de fichiers est légère. Par conséquent, un serveur unique peut fournir des partages de fichiers pour plusieurs environnements de CCR. Toutefois, chaque environnement de CCR doit disposer de ses propres dossier et partage dédiés sur ce serveur.

Considérations relatives au témoin de partage de fichier

La réplication continue en cluster est un environnement à deux noeuds qui utilise un quorum MNS avec témoin de partage de fichiers ou un quorum de noeuds et de partages de fichiers majoritaire, au lieu d'un troisième noeud (voire davantage) dans le cluster requis pour les clusters MNS traditionnels. Un environnement de réplication continue en cluster dispersé géographiquement est un déploiement de centre de données dans lequel un noeud actif est déployé dans le premier centre, et un noeud passif dans le deuxième. Par conséquent, dans un environnement de réplication continue en cluster dispersé géographiquement, deux options sont disponibles pour le placement d'un partage de fichiers : soit dans le centre de données principal, soit dans un centre tiers.

La première option consiste à configurer le partage de fichiers sur un serveur de transport Hub dans le centre de données principal. Il est recommandé d'utiliser un serveur de transport Hub pour s'assurer qu'un administrateur de messagerie puisse gérer et surveiller les interruptions de partages de fichiers. Notre expérience et les commentaires clients indiquent que les types les plus courants d'interruption du service réseau se produisent dans des topologies de connexions de réseau étendu (WAN). Placer le partage de fichiers dans le centre de données principal permet d'empêcher les interruptions de service dues à des défaillances de réseau entre les deux centres de données. L'utilisation de cette configuration signifie qu'un basculement automatique ne se produira pas en cas d'interruption du centre de données principal. Toutefois, elle permet de s'assurer que la majorité des clusters avec basculement n'est pas affectée par une défaillance de réseau entre les centres de données principal et secondaire.

La deuxième option consiste à configurer le partage de fichiers sur un rôle serveur au sein d'un site physique tiers. Un rôle serveur géré est un serveur qui est pris en charge et géré au même niveau que d'autres serveurs essentiels pour la remise du service de messagerie. Un exemple de rôle serveur géré est un serveur de transport Hub dans le centre de données principal. Ce site physique tiers peut être une filiale ou un centre de données tiers. Dans cette configuration, le site tiers doit avoir une infrastructure réseau aux centres de données principal et secondaire avec une latence lente et une haute fiabilité.

Réplication et relecture du journal des transactions

La réplication et la relecture du journal des transactions permettent de copier les données modifiées et de mettre à jour la base de données de la copie passive. La réplication tire parti de l'historique des modifications produit par le moteur de stockage extensible. Cet historique des modifications est représenté comme une suite de fichiers journaux de taille fixe de 1 mégaoctet (Mo). La fonctionnalité de réplication copie les fichiers journaux vers le noeud passif au fur et à mesure de leur génération. Le mécanisme de réplication est asynchrone sur la base de données en ligne. Lorsque les journaux parviennent au noeud passif, leur intégrité est vérifiée, puis ils sont relus dans la copie de la base de données stockée sur le noeud passif. Le processus de relecture apporte les modifications décrites dans le journal des modifications à la base de données du noeud passif, faisant ainsi correspondre la base de données du noeud passif à la base de données de production moyennant un léger décalage dans le temps.

Comme les données sont répliquées entre les noeuds, le serveur de boîtes aux lettres en cluster peut opérer sur les deux noeuds du cluster. Cette fonctionnalité offre une disponibilité accrue du fait que les interruptions programmées et les défaillances d'un noeud n'entraînent pas d'interruption prolongée du serveur de boîtes aux lettres en cluster. En outre, les interruptions de service de stockage sur un noeud n'ont pas d'impact sur la disponibilité de l'autre noeud et du serveur de boîtes aux lettres en cluster. En supposant que le partage de fichiers soit encore disponible et qu'il puisse communiquer avec le noeud passif, une interruption du noeud actif entraîne le déplacement du serveur de boîtes aux lettres en cluster vers un noeud restant et continue à opérer.

Dans un environnement CCR, le dossier du fichier journal de transactions du noeud actif est partagé à l'aide d'un partage de fichiers Windows standard. L’identificateur global unique (GUID) d'objet du groupe de stockage est utilisé comme nom de partage et un signe dollar ($) est ajouté à la fin du partage. Le service de réplication Microsoft Exchange du noeud passif se connecte au partage sur le noeud passif et copie ou extrait les fichiers journaux à l'aide du protocole SMB (Server Message Block). Le noeud passif vérifie ensuite le fichier journal et le relit dans la copie de la base de données du noeud passif.

Notes

Le trafic SMB de la réplication du fichier journal de transactions n'est pas chiffré. Le cas échéant, vous pouvez utiliser le protocole IPsec (Internet Protocol security) pour chiffrer ce trafic. Seule la réplication du fichier journal de transactions se produit à l'aide du protocole SMB. Le réamorçage d'une copie passive se produit lors de l'utilisation de l'API de sauvegarde ESE, qui est une communication non chiffrée. Le cas échéant, IPSec peut être utilisé pour chiffrer ces données.

Réplication continue sur des réseaux de clusters redondants

Dans la version de publication (RTM) de Microsoft Exchange Server 2007, toutes les activités de copie et d'amorçage de fichier journal dans un environnement de CCR ont lieu sur le réseau public. Les limites de cette configuration sont les suivantes :

  • Lorsque le noeud passif n'est pas disponible pendant plusieurs heures, un nombre significatif de journaux doit être transféré. Le déplacement de ces journaux doit être aussi rapide que possible lorsque le noeud passif est disponible. En copiant les journaux sur le réseau public, leur déplacement entre en compétition ave le trafic client. Cela affecte le trafic client et ralentit la resynchronisation.

  • Lorsque le réseau public subit une défaillance, le basculement est incomplet, et ce même si les données des journaux sont disponibles.

  • Un réseau isolé pour les communications des journaux permet de sécuriser les données de messagerie sans utiliser le chiffrage et ses altérations de performances.

  • Des bourrasques de journaux peuvent se produire sous certaines circonstances. Lorsqu'elles se produisent, le système expérimente une charge de réplication élevée inhabituelle. Cela peut provoquer une insuffisance au niveau du client si les données des journaux doivent être communiquées sur le réseau utilisé pour communiquer avec les clients.

Tous ces problèmes ne se produisent pas avec la même fréquence. Toutefois, le premier problème se produit effectivement tous les cinq mois car les noeuds passifs sont mis hors ligne pour les activités normales de maintenance.

Exchange 2007 SP1 réduit les effets des problèmes évoqués ci-avant en permettant à l'administrateur de créer un ou plusieurs réseaux mixtes dans le cluster (un réseau mixte est un réseau de clusters qui prend en charge le trafic d'interrogations du cluster interne et le trafic client) pour l'envoi de journaux. Exchange 2007 SP1 permet également à l'administrateur de spécifier un réseau mixte spécifique pour l'amorçage.

Notes

Les réseaux de clusters utilisés pour l'envoi de journaux et l'amorçage doivent être configurés comme réseaux mixtes. Un réseau mixte est tout réseau de clusters configuré pour un trafic de cluster (interrogation) et un trafic accès au client. En outre, sur la carte réseau en cours de configuration avec un nom d'hôte de réplication continue, l'administrateur doit désactiver la case à cocher Enregistrer les adresses de cette connexion dans le DNS dans la boîte de dialogue Paramètres TCP/IP avancés et utiliser des entrées DNS statiques ou des entrées de fichiers d’hôtes sur chaque nœud pour permettre la résolution de nom pour les noms d’hôte nouvellement créés par chaque nœud. Le serveur DNS utilisé par la carte réseau peut se trouver sur le réseau public ou privé ; toutefois, indépendamment de son emplacement, il doit être accessible aux deux noeuds de façon à ce que la résolution du nom d'hôte soit possible. En outre, sur Windows Server 2008, les cartes réseau utilisés pour l'envoi ou l'amorçage nécessitent l'activation de NetBIOS.

La prise en charge de la copie de fichier journal sur un réseau mixte est configurée à l'aide de la nouvelle cmdlet Enable-ContinuousReplicationHostName. De même, cette fonctionnalité est désactivée à l'aide de la cmdlet Disable-ContinuousReplicationHostName.

Quand un serveur de boîtes aux lettres en cluster existe dans un environnement de CCR, un administrateur peut exécuter la cmdlet Enable-ContinuousReplicationHostName sur les deux noeuds du cluster et spécifier des adresses IP et des noms d'hôte supplémentaires, qui seront ensuite créés dans les groupes de cluster dédiés associés à chaque noeud. Après l'exécution de cette tâche, le service de réplication Microsoft Exchange utilise le réseau nouvellement créé pour la copie de journaux peu après la réussite de la configuration et après confirmation que le nouveau réseau est opérationnel. Si plusieurs réseaux sont créés, le service de réplication Microsoft Exchange sélectionnera aléatoirement l'un d'entre eux. Si le réseau spécifié est indisponible, le service de réplication Microsoft Exchange commencera automatiquement par utiliser les autres réseaux de réplication ; si aucun réseau n'est disponible, il commencera par utiliser le réseau public pour l'envoi de journaux dans les cinq minutes. (La découverte du réseau du service de réplication Microsoft Exchange se produit toutes les cinq minutes). Lorsque le réseau de réplication préféré est à nouveau disponible, le service de réplication Microsoft Exchange recommence à l'utiliser pour l'envoi des journaux.

Pour plus d'informations sur ces cmdlets, consultez les rubriques Enable-ContinuousReplicationHostName et Disable-ContinuousReplicationHostName.

La prise en charge de l'amorçage sur un réseau de clusters redundant est configurée à l'aide de la commande Update-StorageGroupCopy , qui a été mise à jour dans Exchange 2007 SP1 pour inclure un nouveau paramètre appelé DataHostNames. Ce paramètre permet de spécifier le réseau en cluster à utiliser pour l'amorçage. Pour plus d'information sur les modifications de la cmdlet Update-StorageGroupCopy dans Exchange 2007 SP1, consultez la rubrique Update-StorageGroupCopy.

Après la création d'un réseau de clusters pour la réplication continue, vous pouvez utiliser la cmdlet Get-ClusteredMailboxServerStatus pour afficher des informations mises à jour sur les réseaux de clusters pour lesquels la réplication continue a été activée. Les nouvelles informations de la sortie incluent :

  • OperationalReplicationHostNames:{Host1,Host2,Host3}

  • FailedReplicationHostNames:{Host4}

  • InUseReplicationHostNames:{Host1,Host2}

Pour plus d'information sur les modifications de la cmdlet Get-ClusteredMailboxServerStatus dans Exchange 2007 SP1, consultez la rubrique Get-ClusteredMailboxServerStatus.

Conteneur de depot de transport

L'essentiel de la perte de données qui se produit lors d'une récupération automatique est automatiquement récupéré par la fonctionnalité du serveur de transport Hub appelée conteneur de dépôt de transport. La benne de transport pour une base de données spécifique peut être localisée sur tous les serveurs de transport Hub dans le site Active Directory contenant le serveur de boîtes aux lettres en cluster. Tandis qu’un message passe les serveurs de transport Hub en se dirigeant vers un serveur de boîtes aux lettres en cluster dans un environnement de CCR, une copie est conservée dans la file d’attente de transport (mail.que) jusqu’à ce que la fenêtre de réplication soit écoulée. Le conteneur de dépôt de transport est un composant requis pour les déploiements de CCR. Le conteneur de dépôt de transport profite de la redondance dans l'environnement pour réclamer une partie des données affectées par le basculement. En l'occurrence, les serveurs de transport Hub conservent une file d'attente du courrier récemment remis. Cette file d'attente dépend de la durée de conservation du courrier et de l'espace total utilisé. Lors d'un basculement qui n'est pas Lossless, la CCR du serveur de boîtes aux lettres en cluster interroge automatiquement chaque serveur de transport Hub dans le site Active Directory pour soumettre de nouveau le courrier présent dans la file d'attente de la benne de transport. La banque d'informations supprime automatiquement les doublons et remet de nouveau les messages perdus.

La benne de transport est activée pour la réplication continue en cluster (CCR) et, dans Exchange 2007 SP1, également pour la réplication continue locale (LCR). La benne de transport n'est pas activée pour la réplication continue de secours (SCR) ou les clusters à copie unique (SCC). Pour la CCR, pour qu'un message électronique se trouve dans la benne de transport, il doit avoir au moins un destinataire dont la boîte aux lettres se trouve dans un serveur de boîtes aux lettres en cluster dans un environnement de CCR ou, dans SP1, sur une base de données de boîtes aux lettres activée pour la LCR.

Le conteneur de dépôt de transport sert à empêcher la perte de données en fournissant à un administrateur la possibilité de configurer la CCR de sorte que le serveur de boîtes aux lettres en cluster soit automatiquement mis en ligne sur un autre noeud, avec une quantité de perte de données limitée. Dans ce cas, le système remet automatiquement tous les messages électroniques récemment envoyés aux utilisateurs de ce serveur, à l'aide du conteneur de dépôt de transport qui stocke ces messages électroniques. Dans la plupart des situations, cela limite la perte de données. Dans un environnement de CCR, les demandes de nouvelle remise de la benne de transport sur tous les serveurs de transport Hub du site sont exécutées automatiquement. Dans Exchange 2007 RTM, l’intervalle de relance est codé de manière irréversible sur sept jours. Dans Exchange 2007 SP1, l’intervalle de relance est égal à la valeur définie pour MaxDumpsterTime. Dans un environnement de LCR, les demandes de nouvelle remise de la benne de transport sur tous les serveurs de transport Hub du site sont effectuées dans le cadre de la tâche Restore-StorageGroupCopy.

Les situations où la perte de données n'est pas compensée par le conteneur de dépôt de transport sont les suivantes :

  • dossier brouillons pour les clients Microsoft Outlook en mode connexion ;

  • rendez-vous, mises à jour des contacts, mises à jour des propriétés, tâches et mises à jour des tâches ;

  • messages sortants en transit du client vers le serveur de transport Hub. Il existe une durée pendant laquelle le message électronique n'existe que sur le serveur de boîtes aux lettres de l'expéditeur.

Déploiement de la réplication continue en cluster

Le déploiement de la CCR est similaire au déploiement d'un serveur Exchange autonome, ainsi qu'au déploiement de SCC. Pour plus d'informations sur les clusters à copie unique, consultez la rubrique Clusters à copie unique. Il existe néanmoins des caractéristiques propres à la CCR qu'il faut connaître. Il est recommandé de consulter les rubriques suivantes avant de concevoir et de déployer la CCR dans votre environnement :

Une fois que vous êtes prêt à déployer la CCR, vous pouvez démarrer le processus en réalisant les étapes de chaque phase d'installation décrites dans l'une des rubriques suivantes :

Améliorations apportées à la CCR dans Exchange 2007 SP1

Exchange 2007 SP1 apporte plusieurs améliorations à la réplication continue en cluster (CCR), notamment l'ajout d'éléments à l'interface utilisateur de la console de gestion Exchange, ainsi qu'une surveillance, un état et des performances améliorés.

Améliorations de la console de gestion Exchange

Plusieurs nouveaux éléments ont été ajoutés à la nouvelle interface utilisateur dans Exchange 2007 SP1, qui améliorent la gestion des fonctionnalités de haute disponibilité, notamment CCR. Ces améliorations sont les suivantes :

  • Interface utilisateur du conteneur de dépôt de transport   Un nouvel onglet Paramètres globaux a été ajouté au noeud du transport Hub sous la zone de travail Configuration de l'organisation. Cet onglet inclut une page Propriétés des paramètres de transport qui permet de configurer les paramètres du conteneur de dépôt de transport de l'organisation :

    • Taille maximale par groupe de stockage (Mo)   Spécifie la taille maximale de la file d'attente du conteneur de dépôt de transport pour chaque groupe de stockage.

    • Période de rétention maximale (jours)   Ce champ spécifie le temps pendant lequel un message électronique doit rester dans la file d'attente de la benne de transport.

  • Réplication continue   Des contrôles d'interface utilisateur supplémentaires ont été ajoutés à la console de gestion Exchange : ils permettent à l'administrateur d'interrompre, de reprendre, de mettre à jour ou de restaurer la réplication continue. Ces contrôles sont équivalents aux cmdlets suivantes de l'environnement de ligne de commande Exchange :

    • Suspend-StorageGroupCopy

    • Resume-StorageGroupCopy

    • Update-StorageGroupCopy

    • Restore-StoreGroupCopy

    Ces cmdlets et les tâches correspondantes de la console de gestion Exchange permettent de gérer la réplication continue dans des environnements LCR et CCR.

Améliorations apportées à l'état et la surveillance

Exchange 2007 SP1 apporte également plusieurs changements destinés à améliorer la gestion d'Exchange 2007. Ces modifications apportent une amélioration par rapport à la version de publication (RTM) de Microsoft Exchange 2007 et incluent des fonctionnalités supplémentaires conçues pour une surveillance proactive des environnements de réplication continue. Pus particulièrement, les modifications et améliorations corrigent les insuffisances connues de la cmdlet Get-StorageGroupCopyStatus, ajoute une cmdlet nommée Test-ReplicationHealth et améliore la visibilité de la fenêtre de perte couverte par le conteneur de dépôt de transport.

Améliorations apportées à la cmdlet Get-StorageGroupCopyStatus dans SP1

Dans Exchange 2007 RTM, il y a plusieurs situations où l'état rapporté par la cmdlet Get-StorageGroupCopyStatus et les compteurs de performance de réplication continue est inexact ou trompeur :

  • Un groupe de stockage inactif (c'est-à-dire qui ne change pas) peut signaler erronément un état sain. Cette situation se produit si la condition malsaine ne peut pas être détectée sans relecture du journal.

  • Durant l'initialisation de la réplication, l'état de la réplication est réévalué et peut être imprécis. Une fois l'initialisation terminée, l'état est mis à jour.

  • La valeur du champ LastLogGenerated peut être erronée en cas de démontage de la base de données dans la groupe de stockage.

  • S'il manque un ou plusieurs journaux au milieu d'une séquence d'un flux de journal, la tentative de récupération par la copie passive se poursuit, ce qui a pour effet de faire basculer l'état de réplication entre les états d'échec et sain. Lorsque cela se produit, les files d'attente de relecture et de copie continuent à s'allonger.

  • Dans quelques rares situations, il est possible de vérifier un journal avec succès même s'il est impossible de le relire. Dans ce cas, pendant la tentative de récupération, le système bascule entre les états d'échec et sain. Lorsque cela se produit, les files d'attente de relecture et de copie continuent à s'allonger.

La cmdlet Get-StorageGroupCopyStatus a également été améliorée par l'ajout de nouvelles informations d'état pour les environnements CCR :

  • La cmdlet Get-StorageGroupCopyStatus rapport un état SummaryCopyStatus de ServiceDown lorsque le service de réplication Microsoft Exchange sur l'ordinateur cible n'est pas accessible sur le réseau.

  • La cmdlet Get-StorageGroupCopyStatus rapporte un état SummaryCopyStatus de Initializing lorsque le service de réplication Microsoft Exchange sur l'ordinateur cible n'a pas achevé ses vérifications initiales au démarrage. Un nouveau compteur de performance a également été créé pour représenter cet état comme une valeur booléenne.

  • La cmdlet Get-StorageGroupCopyStatus rapporte un état SummaryCopyStatus de Synchronizing lorsqu'elle n'a pas achevé un réamorçage incrémentiel.

Les nouveaux états pour la valeur SummaryCopyStatus ne sont visibles que si vous utilisez la version Exchange 2007 SP1 des outils de gestion Exchange. Si vous utilisez la version Exchange 2007 RTM des outils de gestion Exchange, l'état rapporté pour chacun des états précédents est Failed.

Cmdlet Test-ReplicationHealth

Exchange 2007 SP1 introduit une nouvelle cmdlet nommée Test-ReplicationHealth. Cette cmdlet est conçue pour exercer une surveillance proactive de la réplication continue et du pipeline de réplication continue. La cmdlet Test-ReplicationHealth vérifie tous les aspects de la réplication, des services de cluster et l'état de réplication et de relecture du groupe de stockage pour donner une vue d'ensemble complète du système de réplication. Plus particulièrement, en cas d'exécution sur un noeud du cluster, la cmdlet Test-ReplicationHealth effectue les tests décrits dans le tableau suivant.

Tests effectués par la cmdlet Test-ReplicationHealth

Test Description

État de réseau de clusters

Vérifie que tous les réseaux gérés par des clusters trouvés sur le noeud local sont en cours d'exécution. Ce test n'est exécuté que dans un environnement de réplication continue en cluster.

État de groupe quorum

Vérifie que le groupe de clusters contenant la ressource quorum est sain. Ce test n'est exécuté que dans un environnement de réplication continue en cluster.

État de quorum de partages de fichiers

Vérifie que la valeur de FileSharePath utilisée par le quorum jeu de noeud majoritaire avec témoin de partage de fichiers est accessible. Ce test n'est exécuté que dans un environnement de réplication continue en cluster.

État de groupe de serveurs de boîtes aux lettres en cluster

Vérifie que le serveur de boîtes aux lettres en cluster est sain en contrôlant que toutes les ressources d'un groupe sont connectées. Ce test n'est exécuté que dans un environnement de réplication continue en cluster.

État de nœud

Vérifie qu'aucun des noeuds du cluster n'est en état de pause. Ce test n'est exécuté que dans un environnement de réplication continue en cluster.

État d'enregistrement DNS

Vérifie que toutes les interfaces réseau gérées par des clusters pour lesquelles l'option $$$Exiger la réussite de l'enregistrement DNS est définie ont fait l'objet d'un enregistrement de DNS réussi. Ce test n'est exécuté que dans un environnement de réplication continue en cluster.

État de service de réplication

Vérifie que le service de réplication Microsoft Exchange sur l'ordinateur local est sain.

Copie de groupe de stockage suspendue

Vérifie si la réplication continue a été suspendue pour un groupe de stockage sur la réplication continue a été activée.

Copie de groupe de stockage en échec

Vérifie s'il existe des copies de groupe de stockage dont l'état est Failed.

Longueur de file d'attente de relecture du groupe de stockage

Vérifie s'il y a un groupe de stockage dont la longueur de file d'attente de copie de réplication est supérieure aux seuils définis par les meilleures pratiques. Actuellement, ces seuils sont les suivants :

  • Avertissement   La longueur de la file d'attente est comprise entre 3 et 5 journaux.

  • Échec   La longueur de la file d'attente est égale ou supérieure à 6 journaux.

Bases de données démontées après basculement

Vérifie si des bases de données sont démontées ou en échec après une basculement. Ce test vérifie uniquement l'existence de bases de données en échec à la suite d'un basculement.

Améliorations des performances

Des améliorations ont été apportées aux performances dans Exchange 2007 SP1, qui auront un impact positif sur les déploiements de haute disponibilité. Ces améliorations sont les suivantes :

  • Réductions d'E/S sur les disques contenant des copies passives de groupes de stockage dans des environnements de réplication continue   Dans Exchange 2007 SP1, la conception de l'architecture de réplication continue a été modifiée de sorte que le cache de base de données est désormais conservé sur le noeud passif entre des lots d'activité de relecture du journal. La conservation du cache de base de données entre des lots d'activité de relecture du journal permet au service de réplication Microsoft Exchange d'exploiter les fonctionnalités de mise en cache de la base de données d'ESE (Extensible Storage Engine) qui, à son tour, réduit le nombre d'entrée/sorties (E/S) de disque qui se produisent sur les numéros d'unité logique (LUN) de la copie passive. En revanche, dans Exchange 2007 RTM, un cache de base de données a été créé pour chaque lot d'activité de relecture du journal, ce qui multiplie parfois par deux ou trois l'activé d'E/S de disque du noeud passif par rapport aux E/S de disque du noeud actif.

  • Déplacement plus rapide des serveurs de bases de données entre des noeuds dans une environnement CCR   Ces améliorations permettent de déplacer des serveurs de boîtes aux lettres en cluster entre les noeuds en moins de deux minutes. Cela inclut des déplacements exécutés par un administrateur (à l'aide de la cmdlet Move-ClusteredMailboxServer), ainsi que des basculements gérés par le service de cluster. Pour exécuter des déplacements rapides dans un environnement CCR, les bases de données sont mises hors ligne sans purge du cache de la base de données. Ce comportement réduit la durée d'indisponibilité d'un serveur de boîtes aux lettres déplacé vers un autre noeud.

Utilisation de la réplication continue de secours avec CCR

SCR est une nouvelle fonctionnalité offerte dans Exchange 2007 SP1. La SCR étend les fonctionnalités de réplication continue existantes et permet de nouveaux scénarios de disponibilité pour les serveurs de boîtes aux lettres Exchange 2007. La SCR utilise la même technologie d’envoi et de relecture des journaux utilisée par la LCR et la CCR afin d'offrir des options et configurations de déploiement supplémentaires.

SCR permet d'utiliser la réplication continue pour répliquer les données d'un serveur de boîtes aux lettres d'un serveur de boîtes aux lettres autonome (avec ou sans LCR) ou d'un serveur de boîtes aux lettres en cluster dans un environnement SCC ou CCR.

Le processus d'activation des copies des données du serveur de boîtes aux lettres créées et gérées par SCR est manuel. Il est conçu pour être utilisé lorsqu'une défaillance importante se produit (et non pas pour de simples interruptions de serveurs qui sont récupérables par un redémarrage ou d'autres moyens rapides). Vous pouvez activer une cible SCR à l'aide de la portabilité de la base de données, de l'option de récupération du serveur (Setup /m:RecoverServer) ou, dans le cas d'un serveur de boîtes aux lettres en cluster, de l'option de récupération du serveur de boîtes aux lettres en cluster (Setup /RecoverCMS). Votre choix s'effectuera en fonction de votre configuration et du type de défaillances rencontrées.

Pour plus d'informations sur la SCR, consultez la rubrique Réplication continue de secours.

Pour plus d'informations

Les rubriques suivantes expliquent quand et comment utiliser la fonction CCR en relation avec un plan de disponibilité élevée et de tolérance aux pannes de site :