Gestion de la réplication continue en cluster
S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Dernière rubrique modifiée : 2009-06-10
En plus des tâches relatives à la gestion et l'administration quotidiennes d'une organisation Exchange, il existe des tâches spécifiques à la gestion d'un environnement de réplication continue en cluster (CCR). En règle générale, les tâches administratives en relation avec la CCR sont regroupées en deux catégories :
tâches en relation avec un serveur de boîtes aux lettres en cluster ;
tâches en relation avec les groupes de stockage et les bases de données présents dans un serveur de boîtes aux lettres en cluster.
Tâches en relation avec un serveur de boîtes aux lettres en cluster
Les tâches administratives associées à un serveur de boîtes aux lettres en cluster dans un environnement de CCR sont les suivantes :
gestion de volumes de disque ;
affichage des paramètres de configuration ;
analyse de l'activité de réplication ;
affichage et collecte de données de performances ;
gestion des serveurs de boîtes aux lettres en cluster, incluant leur mise en ligne, leur mise hors ligne et le déplacement des serveurs entre des noeuds ;
gestion de la réplication et de la relecture de fichier journal.
Gestion des volumes de disque
Lors de la gestion d'un environnement CCR, il peut être nécessaire de gérer des volumes de disque associés à votre cluster CCR. Par exemple, le volume peut nécessiter un détachement temporaire du système pour des raisons de maintenance ou autres. Si cela doit se passer sur un groupe de stockage actif ou sur une base de données active, les bases de données du groupe de stockage doivent être démontées. Si une telle opération doit être exécutée sur la copie passive du groupe de stockage ou de la base de données, toutes les entrées/soties (E/S) de réplication sur le volume doivent être arrêtées en arrêtant la réplication.
Pour plus d'informations sur la gestion des volumes de disque, consultez la rubrique Procédure de préparation pour les activités de gestion de volumes de disque pour une copie de CCR.
Affichage des paramètres de configuration
Une fois la réplication continue en cluster (CCR) activée pour un serveur, vous pouvez utiliser la console de gestion Exchange et l'environnement de ligne de commande Exchange Management Shell pour afficher les paramètres de configuration des groupes de stockage et des bases de données sur le serveur.
Les informations de configuration comprennent les emplacements du groupe de stockage et des fichiers de bases de données. En outre, vous pouvez consulter la configuration du serveur de boîtes aux lettres en cluster à l'aide de l'environnement de ligne de commande Exchange Management Shell.
Pour obtenir la procédure détaillée pour l'affichage des informations de configuration de basculement de contrôle de CCR, consultez la rubrique Procédure d'affichage de la configuration de contrôle du basculement.
Analyse de l'activité de réplication
La copie passive d'une base de données est utile uniquement si elle est mise à jour régulièrement. Bien que la CCR ne requière pas d'analyse particulière, il est recommandé d'analyser régulièrement chaque groupe de stockage pour vérifier qu'il réplique correctement les fichiers journaux. Le pack d'administration Microsoft Exchange Server 2007 pour Microsoft Operations Manager 2005 inclut des alertes pour plusieurs problèmes critiques liés aux environnements de CCR :
Le service de réplication de Microsoft Exchange n'est pas en cours d'exécution sur le noeud passif. L'événement qui génère cette alerte ne s'affiche pas à plusieurs reprises après l'arrêt du service, de sorte que l'alerte qui lui est associée est perdue si elle a été désactivée.
La copie passive est en état d'échec.
La copie passive est dans un état sain mais elle est en retard en ce qui concerne la copie ou la relecture de journaux.
Il est également recommandé d'ajouter une règle d'événement personnalisée à Microsoft Operations Manager, qui est déclenchée lorsqu'un noeud passif est détecté comme inactif et qu'une partie du cluster contient un noeud actif. Lorsque cette condition survient, le service de cluster enregistre un événement dans le journal des événements système. Il est recommandé d'utiliser les critères suivants pour la règle d'événement qui fera partie de l'événement enregistré par le service de cluster :
Source de l'événement : ClusSvc
ID d'événement : 1135
Pour plus d'informations sur la création de règles d'événement dans Microsoft Operations Manager, visitez la page sur l'analyse des événements de sécurité avec MOM.
Vous devez étudier et résoudre au plus vite toutes les alertes ci-dessus générées par le pack d'administration Exchange 2007 ou une règle d'événement personnalisée.
Une alternative à l'utilisation du pack d'administration Exchange 2007 pour Microsoft Operations Manager 2005 est l'exécution régulière de la cmdlet Get-StorageGroupCopyStatus dans un script dans l'environnement de ligne de commande Exchange Management Shell. La cmdlet Get-StorageGroupCopyStatus indique la longueur des files d'attente et spécifie le nombre de journaux générés par le noeud actif. Pour des raisons de performances, les compteurs de performance relatifs à la longueur des files d'attente indiquent uniquement les informations connues par le service de réplication Microsoft Exchange. Dans certaines conditions rares, il peut arriver que les résultats soient incohérents par rapport à l'état du noeud actif. Pour plus d'informations sur la cmdlet Get-StorageGroupCopyStatus, consultez la section « Affichage de l'état des copies du groupe de stockage » ci-après dans cette rubrique.
Affichage et collecte de données de performances
Les compteurs de performance permettent de déterminer la progression de la réplication. Pour plus d'informations sur les compteurs de performance pour la CCR, consultez la rubrique Procédure d'affichage des compteurs de performance pour la réplication continue en cluster.
Gestion de serveurs de boîtes aux lettres en cluster
Les trois principales tâches administratives pour la gestion d'un serveur de boîtes aux lettres en cluster sont sa mise en ligne, sa mise hors ligne, et le déplacement du serveur de boîtes aux lettres en cluster entre des noeuds dans le cluster. Cela peut également concerner la fermeture ou le redémarrage de l'un des noeuds du cluster dans le cadre d'opérations de gestion des mises à jour ou de maintenance diverses.
Démarrage et arrêt d'un serveur de boîtes aux lettres en cluster
L'outil Gestion du cluster de basculement (Windows Server 2008), l'administrateur de cluster (Windows Server 2003) et l'outil de ligne de commande Cluster.exe (dans les deux systèmes d'exploitation) peuvent connecter et déconnecter des ressources. La déconnexion d'un serveur de boîtes aux lettres en cluster est appelée arrêt ; la mise en ligne d'un serveur de boîtes aux lettres en cluster est appelée démarrage. La méthode recommandée pour démarrer un serveur de boîtes aux lettres en cluster consiste à utiliser la cmdlet Start-ClusteredMailboxServer. La manière recommandée pour arrêter un serveur de boîtes aux lettres en cluster consiste à utiliser la cmdlet Stop-ClusteredMailboxServer. Dans Exchange 2007 Service Pack 1 (SP1), vous pouvez également utiliser l'Assistant Gestion de serveur de boîtes aux lettres en cluster dans la console de gestion Exchange pour démarrer ou arrêter un serveur de boîtes aux lettres en cluster.
Pour obtenir la procédure détaillée de connexion d'un serveur de boîtes aux lettres en cluster, consultez la rubrique Procédure de démarrage d'un serveur de boîtes aux lettres en cluster. Pour obtenir la procédure détaillée de déconnexion d'un serveur de boîtes aux lettres en cluster, consultez la rubrique Procédure d'arrêt d'un serveur de boîtes aux lettres en cluster.
Déplacement d'un serveur de boîtes aux lettres en cluster entre des noeuds
Le déplacement manuel d'un serveur de boîtes aux lettres en cluster entre des noeuds est appelé transfert ou interruption programmée. Pour déplacer un serveur de boîtes aux lettres en cluster, utilisez la cmdlet Move-ClusteredMailboxServer. Dans Exchange 2007 SP1, vous pouvez également utiliser l'Assistant Gestion de serveur de boîtes aux lettres en cluster dans la console de gestion Exchange pour opérer le transfert d'un serveur de boîtes aux lettres en cluster. Bien que l'outil Gestion du cluster de basculement (Windows Server 2008), l'Administrateur de cluster (Windows Server 2003) et l'outil de ligne de commande Cluster.exe (dans les deux systèmes d'exploitation) permettent de déplacer un serveur de boîtes aux lettres en cluster entre des nœuds, il est recommandé d'utiliser l'un des outils de gestion Exchange pour déplacer un serveur de boîtes aux lettres en cluster du nœud actif vers le nœud passif car ils permettent de spécifier un motif pour le transfert. En outre :
L'utilisation des outils du cluster ignore le contrôle de l'intégrité ou de l'état de la copie passive qui est effectué par les outils de gestion Exchange. Aussi leur utilisation peut-elle entraîner une interruption prolongée pendant que le noeud exécute les opérations nécessaires pour rendre la base de données montable.
L'utilisation des outils du cluster peut également laisser une base de données déconnectée indéfiniment parce que la réplication n'est pas intègre et parce que les outils du cluster, à la différence des outils de gestion Exchange, sont incapables de déterminer l'état de la réplication avant de déplacer le groupe de ressources.
Notes
Le déplacement d'un serveur de boîtes aux lettres en cluster entre des noeuds entraîne une brève interruption du service. En outre, toute sauvegarde de groupe de stockage sur le serveur de boîtes aux lettres en cluster est abandonnée.
Si la réplication n'est pas intègre ou si ces contrôles déterminent que le noeud passif n'est pas dans un état acceptable pour le transfert, les outils de gestion Exchange n'effectuent pas le transfert. Si cela se produit et que vous deviez encore déplacer le serveur de boîtes aux lettres en cluster vers le noeud passif, vous pouvez utiliser les outils de gestion du cluster pour ce faire.
Lors du déplacement d'un serveur de boîtes aux lettres en cluster dans un cluster avec basculement dans lequel il y a un temps de réponse du réseau, il est recommandé d'exécuter l'opération de déplacement à partir du noeud passif.
Pour obtenir la procédure détaillée de déplacement d'un serveur de boîtes aux lettres en cluster entre des noeuds, consultez la rubrique Procédure de déplacement d'un serveur de boîtes aux lettres dans un environnement de CCR.
Exécution des tâches de maintenance d'un cluster
La maintenance doit toujours être effectuée sur le noeud passif du cluster. En général, les mises à jour, les correctifs et autres applications ne doivent pas être installés sur le noeud actif (noeud sur lequel se trouve un serveur de boîtes aux lettres en cluster). Pour obtenir la procédure détaillée d'installation de correctifs cumulatifs Exchange dans un environnement de réplication continue en cluster, consultez la rubrique Appliquer les correctifs cumulatifs Exchange 2007 aux serveurs de boîtes aux lettres en cluster.
Si la maintenance doit être effectuée sur le noeud actif, alors le serveur de boîtes aux lettres en cluster doit d'abord être déplacé sur un noeud passif à l'aide de la cmdlet Move-ClusteredMailboxServer. Une fois le déplacement du serveur de boîtes aux lettres en cluster effectué, le noeud précédemment actif devient le noeud passif et inversement. Il est ensuite possible de procéder à la maintenance. Une procédure de transfert permettant de déplacer le serveur de boîtes aux lettres en cluster dans le sens contraire peut être effectuée.
Les environnements de réplication continue en cluster permettent de planifier une interruption de système d'un noeud spécifique sans interruption du serveur de boîtes aux lettres en cluster. Dans un environnement de CCR, il n'est possible de déconnecter qu'un seul noeud à la fois. La déconnexion de plus d'un noeud provoque une interruption dans le service.
Une interruption planifiée est initiée via la cmdlet de l'environnement de ligne de commande Exchange Management Shell Move-ClusteredMailboxServer. La rubrique Procédure de déplacement d'un serveur de boîtes aux lettres dans un environnement de CCR contient une procédure décrivant l'exécution d'une interruption planifiée.
Avant d'arrêter ou de redémarrer un noeud dans un environnement de réplication continue en cluster, il est recommandé d'identifier le noeud hébergeant actuellement le serveur de boîtes aux lettres en cluster. Pour ce faire, utilisez la cmdlet Get-ClusteredMailboxServerStatus.
Exécution des tâches de maintenance d'un cluster
La maintenance doit toujours être effectuée sur le noeud passif du cluster. En général, les mises à jour, correctifs et autres applications ne doivent pas être installés sur le noeud actif (noeud sur lequel se trouve un serveur de boîtes aux lettres en cluster). Pour obtenir la procédure détaillée d'installation de correctifs cumulatifs Exchange dans un environnement de réplication continue en cluster, consultez la rubrique Appliquer les correctifs cumulatifs Exchange 2007 aux serveurs de boîtes aux lettres en cluster.
Si la maintenance doit être effectuée sur le noeud actif, alors le serveur de boîtes aux lettres en cluster doit d'abord être déplacé sur le noeud passif à l'aide de la cmdlet Move-ClusteredMailboxServer. Une fois le déplacement du serveur de boîtes aux lettres en cluster effectué, le noeud précédemment actif devient le noeud passif et inversement. Il est ensuite possible de procéder à la maintenance. Une procédure de transfert permettant de déplacer le serveur de boîtes aux lettres en cluster dans le sens contraire peut être effectuée.
Arrêt des noeuds du cluster
Si tous les noeuds du cluster doivent être arrêtés, y compris le noeud actif, vous devez d'abord arrêter le serveur de boîtes aux lettres en cluster. Le processus d'arrêt de Windows n'est pas compatible avec Exchange. C'est pourquoi il est recommandé de n'arrêter que les noeuds passifs. S'il est nécessaire d'arrêter ou de redémarrer un nœud actif, il est recommandé de déplacer le serveur de boîtes aux lettres en cluster vers un autre nœud disponible. Pour obtenir la procédure détaillée de déplacement d'un serveur de boîtes aux lettres en cluster dans un autre noeud, consultez la rubrique Procédure de déplacement d'un serveur de boîtes aux lettres dans un environnement de CCR.
Si le serveur de boîtes aux lettres en cluster ne peut pas être déplacé sur le noeud passif (il se peut que le noeud passif soit déjà arrêté), il doit être arrêté avant le noeud actif.
Si vous devez redémarrer ou arrêter le noeud actif et que vous ne pouvez pas déplacer le serveur de boîtes aux lettres en cluster vers le noeud passif, il est recommandé d'utiliser une stratégie de groupe pour vous assurer que le serveur de boîtes aux lettres en cluster est arrêté avant le redémarrage ou l'arrêt d'un noeud actif. Windows Server fournit un ensemble de scripts d'arrêt d'ordinateur répondant à une stratégie que vous pouvez gérer à l'aide du composant logiciel enfichable Stratégie de groupe. Le composant logiciel enfichable Stratégie de groupe inclut des extensions qui vous permettent de spécifier un script s'exécutant lorsque vous arrêtez l'ordinateur.
Par exemple, vous pouvez créer un script d'arrêt qui exécute la cmdlet Move-ClusteredMailboxServer ou Stop-ClusteredMailboxServer, avec les paramètres appropriés. L'utilisation d'un script d'arrêt est également recommandée car cela réduit la probabilité que le système soit arrêté ou redémarré par un administrateur qui ignore qu'il faut déplacer ou arrêter le serveur de boîtes aux lettres en cluster avant l'arrêt du noeud actif.
.gif "important") Important : |
|---|
| Ces scripts sont exécutés sous le compte Système local. Pour que ces scripts puissent être exécutés correctement, vous devez octroyer au compte système local (le compte d'ordinateur du nœud local) les autorisations nécessaires pour gérer le serveur de boîtes aux lettres en cluster. |
Gestion de la réplication et de la relecture de fichier journal
La gestion de la réplication dans un environnement CCR implique les activités principales suivantes :
gestion des basculements en cas d'arrêt de la réplication ;
arrêt et redémarrage de la réplication sur des copies de groupe de stockage ;
configuration d'un ou plusieurs réseaux redondants pour la réplication.
Gestion des basculements en cas d'arrêt de la réplication
L'arrêt de la réplication met fin à la propagation des modifications depuis le groupe de stockage actif vers la copie pour la période de suspension. En cas de basculement, la copie du groupe de stockage ne contient pas les dernières modifications. En fonction du volume de modification opérée sur le noeud actif, l'absence des dernières modifications peut empêcher le système de monter la copie sur l'ordinateur passif. Par conséquent, vous pouvez utiliser la version disponible du groupe de stockage sur le noeud passif ou patienter jusqu'à la récupération du serveur original. Il est important de minimiser le temps d'arrêt de la réplication pour minimiser cette exposition.
Si vous ne montez pas la version des données sur le noeud passif lorsque l'ordinateur original devient disponible, le système de réplication copie les journaux manquants et monte automatiquement la copie des bases de données sur le nouveau noeud actif.
Un basculement suite à la reprise d'une réplication peut avoir lieu quand la copie passive ne dispose pas encore de tous les journaux ou avant la relecture de l'ensemble des journaux. Si les journaux sont copiés mais pas relus, un basculement déclenche la relecture des journaux en attente dans la base de données. Par conséquent, ce groupe de stockage connaît un temps de récupération étendu en relation avec le basculement, même si les autres groupes de stockage ne sont pas affectés. En revanche, si le nombre de journaux disponibles est suffisant pour satisfaire aux critères de montage automatique configurés, le système monte éventuellement la base de données avec les dernières données disponibles. Ce processus comporte un risque : Un des journaux relus peut être endommagé et empêcher une relecture satisfaisante. Dans ce cas, la relecture génère une erreur et toute relecture ultérieure est bloquée. Dans ce cas, la copie du groupe de stockage génère un état d'erreur de type « Échec ». Il se peut que vous soyez alors en mesure d'effectuer une récupération à l'aide de la version de la base de données jusqu'au point problématique. Sinon, vous devez attendre que le serveur original soit disponible et que le journal non endommage soit de nouveau copié.
Arrêt et redémarrage de la réplication sur des copies de groupe de stockage
Il peut parfois être nécessaire de contrôler les activités de la copie passive. Il peut être nécessaire d'arrêter et de redémarrer l'activité de réplication. La réplication est contrôlée au niveau du groupe de stockage. Étant donné qu’un un groupe de stockage ne peut contenir qu'une seule base de données, la réplication a lieu sur une seule base de données.
La réplication s'opère lorsque les noeuds du cluster sont opérationnels, que le service de réplication Microsoft Exchange s'exécute sur le noeud cible et que la copie du groupe de stockage est activée. Si l'emplacement source ou cible de la CCR devient indisponible, vous devez arrêter la réplication. En outre, certaines tâches administratives de CCR, telles que l'amorçage, l'exécution de contrôles d'intégrité ou la reconfiguration du stockage nécessitent une copie du groupe de stockage pour que sa réplication soit arrêtée. Si vous devez arrêter tout accès aux fichiers journaux et aux répertoires des journaux de la cible, vous devez arrêter la réplication.
Exchange 2007 requiert que l'activité de réplication soit interrompue en cas de modification de l'emplacement du groupe de stockage ou de la base de données.
Pour plus d'informations sur l'arrêt des mises à jour de copie de base de données, consultez la rubrique Procédure d'arrêt de la réplication sur une copie de réplication continue en cluster. Pour plus d'informations sur le redémarrage des mises à jour de copie de base de données, consultez la rubrique Procédure de redémarrage de la réplication sur une copie de réplication continue en cluster.
Pour plus d'informations sur l'exécution d'un contrôle d'intégrité sur des journaux des transactions CCR et des fichiers de base de données, consultez la rubrique Procédure de vérification d'une copie de réplication continue en cluster à l'aide d'Eseutil.
Configuration d'un ou plusieurs réseaux redondants pour la réplication
Exchange 2007 SP1 vous permet de configurer des réseaux de clusters redondants utilisables pour l'envoi et l'amorçage de journal dans un environnement de réplication continue en cluster. Le réseau redondant doit être configuré en tant que réseau de clusters mixte. Un réseau de clusters mixte est tout réseau de clusters configuré pour un trafic de cluster (interrogation) et d'accès au client.
Lorsqu'un réseau de cluster mixte a été configuré avec des noms d'hôte et adresses IP de réplication continue, Exchange 2007 utilise ce réseau pour l'envoi de journaux. En outre, le réseau configuré est disponible pour un amorçage initié par l'administrateur avec la cmdlet Update-StorageGroupCopy. Il est possible de spécifier plusieurs réseaux mixtes et, si plusieurs réseaux sont disponibles, Exchange 2007 sélectionne l'un des réseaux de façon aléatoire. Si le réseau actuellement utilisé devient indisponible, Exchange 2007 sélectionne automatiquement un autre réseau disponible.
La prise en charge de l'envoi de journal sur un réseau mixte est configurée à l'aide de la 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 deux adresses IP et noms d'hôte. Une fois cette opération effectuée, le système sélectionne de façon aléatoire un réseau mixte pour la copie de journal après la réussite de la configuration et après vérification du caractère opérationnel du réseau mixte.
L'amorçage et le réamorçage dans un environnement de CCR s'effectue à l'aide de la cmdlet Update-StorageGroupCopy. Dans Exchange 2007 SP1, cette cmdlet a été étendue pour inclure un nouveau paramètre nommé DataHostNames. Ce paramètre est utilisé pour spécifier le réseau à utiliser pour l'amorçage et le réamorçage. La valeur est une liste de plusieurs valeurs de deux noms : soit un nom de domaine complet (FQDN), soit un nom d'hôte. L'un de ces noms doit identifier un noeud passif.
Pour plus d'informations sur la configuration de réseaux redondants pour l'envoi et l'amorçage de journal, consultez les rubriques suivantes :
Réplication continue en cluster sur Windows Server 2008 :
Réplication continue en cluster sur Windows Server 2003 :
Tâches en relation avec les groupes de stockage et les bases de données dans un serveur de boîtes aux lettres en cluster
Les tâches administratives associées aux groupes de stockage et aux bases de données sur un serveur de boîtes aux lettres en cluster dans un environnement de réplication continue en cluster sont les suivantes :
déplacement des fichiers ou d'une base de données d'un groupe de stockage ;
affichage de l'état des copies du groupe de stockage ;
montage et démontage de bases de données ;
vérification de l'intégrité de la copie d'un groupe de stockage ;
récupération suite à l'endommagement d'un groupe de stockage de production ou d'une copie de groupe de stockage ;
restauration de la réplication continue en cluster suite à une défaillance ou un endommagement de données.
À l'exception du groupe de stockage de récupération qui est un type spécial de groupe de stockage, la totalité des groupes de stockage et des bases de données dans un environnement de CCR sont automatiquement activés pour la réplication continue. S'il est possible de suspendre la réplication et la relecture, la désactivation de la réplication continue pour un ou plusieurs groupes de stockage dans un environnement de CCR est impossible parce qu'elle permettrait une interruption pour empêcher l'accès à des bases de données particulières.
Lorsque vous créez un groupe de stockage dans un environnement de CCR, l'amorçage de la copie de la base de données sur le noeud passif doit démarrer automatiquement. Si, pour une raison quelconque, l'amorçage ne s'effectue pas automatiquement, vous devez amorcer manuellement la copie de la base de données. Pour obtenir la procédure détaillée d'amorçage d'une copie de base de données, consultez la rubrique Procédure d'amorçage de la copie de réplication continue en cluster.
Modification de l'emplacement des fichiers ou d'une base de données de groupe de stockage
Il peut être nécessaire de modifier l'emplacement des fichiers d'un groupe de stockage ou l'emplacement d'une base de données dans un environnement de CCR. La durée du déplacement des fichiers dépend de la taille de la base de données déplacée, du nombre de fichiers journaux des transactions déplacés et des caractéristiques de performance du stockage. La base de données est démontée lors d'un déplacement.
Dans un environnement de réplication continue en cluster, le déplacement d'un groupe de stockage requiert le déplacement cohérent des deux copies car l'emplacement des fichiers doit être identique sur le noeud actif et sur le noeud passif. Avant de déplacer un groupe de stockage ou sa base de données, vous devez démonter la base de données et suspendre la réplication. Pour la copie active, vous pouvez l'effectuer à l'aide de la cmdlet Dismount-Database dans l'environnement de ligne de commande Exchange Management Shell. Pour le service de réplication de Microsoft Exchange, utilisez les cmdlets Suspend-StorageGroupCopy et Resume-StorageGroupCopy.
Notes
Le service de réplication Microsoft Exchange analyse en permanence les fichiers à l'emplacement de la copie et dans les journaux sur le noeud actif. Par conséquent, si vous manipulez des journaux actifs, vous devez suspendre l'activité de ce groupe de stockage en utilisant la cmdlet Suspend-StorageGroupCopy qui arrête la réplication.
Pour obtenir la procédure détaillée de modification de l'emplacement des fichiers d'un groupe de stockage dans un environnement de CCR, consultez la rubrique Procédure de déplacement d'un groupe de stockage dans un environnement de CCR. Pour obtenir la procédure détaillée de modification de l'emplacement d'une base de données dans un environnement de CCR, consultez la rubrique Procédure de déplacement d'une base de données dans un environnement de réplication continue en cluster.
Affichage de l'état de copies du groupe de stockage
Dans la version de publication (RTM) de Microsoft Exchange 2007, vous ne pouvez afficher les informations d'état de CCR qu'à l'aide de l'environnement de ligne de commande Exchange Management Shell. Dans Exchange 2007 SP1, il est possible d'afficher certaines des informations d'état répertoriées dans le tableau suivant dans la console de gestion Exchange.
Exchange 2007 publie diverses informations d'état concernant les copies de groupe de stockage. Le tableau suivant décrit les informations d'état disponibles. Le tableau suivant répertorie les attributs selon leur ordre d'apparition dans la sortie complète de la cmdlet Get-StorageGroupCopyStatus. Pour obtenir la procédure détaillée d'affichage des informations d'état, consultez la rubrique Procédure d'affichage de l'état d'une copie de réplication continue en cluster à l'aide d'Exchange Management Shell.
Informations d'état disponibles pour les groupes de stockage activés pour la CCR
| Attribut | Description |
|---|---|
Identity |
Identité du groupe de stockage interrogé. Cet attribut génère le <Nom_serveur>\<Nom_groupe_de_stockage>. |
StorageGroupName |
Nom du groupe de stockage interrogé. Cet attribut génère le nom du groupe de stockage. |
SummaryCopyStatus |
État général actuel de la copie passive. Les valeurs possibles sont les suivantes :
Exchange 2007 SP1 ajoute les valeurs d'état supplémentaires suivantes :
|
Échec |
Vérification de la base de données ou des journaux ayant identifié une incohérence qui empêche la réplication. De même, il y a un problème de configuration ou d'accès au niveau de la copie active ou passive. Les valeurs possibles sont True et False. |
FailedMessage |
Le message textuel qui identifie la condition à l'origine de l'échec de la réplication. Il se peut que ce ne soit pas la seule zone où se présente un problème de réplication. |
Amorçage |
Indique qu'un amorçage est en cours. Les valeurs possibles sont True et False. |
Suspend |
Indique que la réplication a été arrêtée pour la copie passive. Cet état empêche l'extension de la base de données et la copie des journaux. Les valeurs possibles sont True et False. |
SuspendComment |
Zone de commentaire facultatif dans laquelle un administrateur peut insérer un motif ou une note expliquant la raison de l'arrêt de l'activité de réplication. |
CopySuspend |
Indique que la copie de journal a été arrêtée pour la copie passive. Cela empêche le changement du répertoire de copie des journaux. Les valeurs possibles sont True et False. |
CopySuspendComment |
Commentaire facultatif de l'administrateur fournissant un motif ou une remarque concernant la cause de l'arrêt de l'activité de copie du journal. |
CopyQueueLength |
Nombre de fichiers journaux de transactions en attente de copie vers le dossier du fichier journal de copie passive. Une copie est considérée comme inachevée tant que son intégrité n'a pas été contrôlée. |
ReplayQueueLength |
Nombre de fichiers journaux de transactions en attente de relecture dans la copie passive. |
LatestAvailableLogTime |
Horodatage sur le groupe de stockage source du nouveau fichier journal de transactions détecté le plus récemment. |
LastCopyNotificationedLogTime |
Temps associé au dernier nouveau journal généré par le groupe de stockage actif et connu pour la copie. |
LastCopiedLogTime |
Horodatage sur le groupe de stockage source de la dernière copie réussie d'un fichier journal de transactions. |
LastInspectedLogTime |
Horodatage sur le groupe de stockage cible de la dernière vérification réussie d'un fichier journal de transactions. |
LastReplayedLogTime |
Horodatage sur le groupe de stockage cible de la dernière relecture réussie d'un fichier journal de transactions. |
LastLogGenerated |
Dernier numéro de génération de journaux connu généré sur la copie active du groupe de stockage. |
LastLogCopied |
Dernier numéro de génération de journaux copié avec succès dans le dossier du journal de copie passive. |
LastLogNotified |
Dernier numéro de génération de journaux généré par le groupe de stockage actif et connu de la copie. |
LastLogInspected |
Dernier numéro de génération de journaux dont la cohérence et l'intégrité ont été inspectées. |
LastLogReplayed |
Dernier numéro de génération de journaux relu avec succès dans la copie passive de la base de données. |
LatestFullBackupTime |
Heure de la dernière sauvegarde complète. |
LastestIncrementalBackupTime |
Heure de la dernière sauvegarde incrémentielle. |
SnapshotBackup |
Indique si la dernière sauvegarde complète était une sauvegarde en continu héritée ou un instantané de sauvegarde VSS. |
SnapshotLatestFullBackup |
Heure de la dernière sauvegarde complète d'instantané. |
SnapshotLatestIncrementalBackup |
Heure de la dernière sauvegarde incrémentielle d'instantané. |
SnapshotLatestDifferentialBackup |
Heure de la dernière sauvegarde différentielle d'instantané. |
SnapshotLatestCopyBackup |
Heure de la dernière sauvegarde de copie d'instantané. |
OutstandingDumpsterRequests |
Demandes en attente et période (haute-basse) pour celles-ci. |
DumpsterStatistics |
Statistiques du conteneur de dépôt de transport à partir de tous les serveurs de transport Hub accessibles. Cette valeur ne s'affiche que si le paramètre DumpsterStatistics est utilisé avec la commande Get-StorageGroupCopyStatus. |
DumpsterStatisticsNotAvailable |
Liste des serveurs de transport Hub inaccessibles. |
Vous pouvez rapidement évaluer l'intégrité de la copie d'un groupe de stockage en consultant les valeurs de SummaryCopyStatus, CopyQueueLength, ReplayQueueLength et LastInspectedLogTime. Ces trois attributs montrent si la copie du groupe de stockage fonctionne correctement et si elle est relativement mise à jour pour la copie et la relecture des journaux. Si les conditions suivantes sont réunies, vous devez en déterminer la cause et corriger le problème :
L'état de la copie n'est pas intègre.
La longueur de la file d'attente de copie est supérieure à 5.
La longueur de la file d'attente de relecture est supérieure à 20.
L'heure de la dernière inspection du journal n'est pas récente. Une inactivité du groupe de stockage peut entraîner cette situation mais elle peut également indiquer l'arrêt du service de réplication Microsoft Exchange.
Vous pouvez calculer les deux valeurs de file d'attente en unités de temps comme suit :
Durée de la file d'attente de copie = LatestAvailableLogTime – LastCopiedLogTime
Durée de la file d'attente de relecture = LatestCopiedLogTime – LastInspectedLogTime
Les valeurs de longueur de file d'attente de relecture et de copie sont disponibles sous la forme de compteurs de performance. Il s'agit des compteurs de performance CopyQueueLength et ReplayQueueLength sous l’objet performance du service de réplication Microsoft Exchange.
Il existe quelques rares scénarios où l'état de la réplication peut induire en erreur. Voici la liste de ces scénarios :
Un groupe de stockage inactif (c'est-à-dire qui ne change pas) peut signaler erronément un état sain. Cette situation peut se produire si la condition malsaine n'a pas pu être détectée avant une relecture du journal.
Durant l'initialisation de la réplication, l'état de la réplication est é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 d'une base de données. Toutefois, tous les journaux avec un contenu d'utilisateur final sont répliqués si la copie du groupe de stockage est en cours de réplication.
S'il manque un ou plusieurs journaux dans une séquence de journaux, la tentative de récupération par la copie passive se poursuit. Ce faisant, l'état de réplication bascule entre les états d'échec et sain. Les files d'attente de relecture et de copie continuent à s'allonger.
Dans quelques rares situations, il est possible de vérifier un journal 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. Les files d'attente de relecture et de copie continuent à s'allonger.
Notes
Dans Exchange 2007 SP1, vous pouvez également utiliser une nouvelle cmdlet appelée Test-ReplicationHealth pour vérifier l'intégrité et l'état des groupes de stockage activés pour la réplication continue. Pour plus d'informations sur la cmdlet Test-ReplicationHealth, consultez la rubrique Test-ReplicationHealth.
Montage et démontage de bases de données
Parfois, il peut être nécessaire de monter ou de démonter des bases de données dans un environnement CCR. Cela peut être requis pour effectuer une reconfiguration ou pour résoudre des problèmes de serveur ou de base de données. Lorsque la base de données est démontée, elle ne peut pas plus être modifiée. Ni la base de données ni les fichiers journal ne peuvent être modifiés lors du démontage de la base de données.
Pour plus d'informations sur le montage des bases de données dans un environnement de CCR, consultez la rubrique Procédure de montage d'une base de données dans un environnement de réplication continue en cluster. Pour plus d'informations sur le démontage des bases de données dans un environnement CCR, consultez la rubrique Procédure de démontage d'une base de données dans un environnement de réplication continue en cluster.
Vérification de l'intégrité de la copie d'un groupe de stockage
Si vous utilisez une réplication continue en cluster (CCR), il est recommandé de vérifier l'intégrité de la copie passive périodiquement en exécutant un contrôle de cohérence physique par rapport aux fichiers de base de données et fichiers journaux de transactions. Un contrôle de cohérence physique examine les journaux des transactions et les fichiers de base de données pour voir s'ils ne sont pas endommagés. Vous pouvez effectuer le contrôle à l'aide de l'outil Utilitaires de base de données Exchange Server (Eseutil.exe). Pour obtenir la procédure détaillée pour l'utilisation d'Eseutil pour vérifier que les journaux des transactions et les fichiers de base de données ne sont pas physiquement endommagés, consultez la rubrique Procédure de vérification d'une copie de réplication continue en cluster à l'aide d'Eseutil.
Notes
Avant d'exécuter un contrôle de cohérence physique par rapport à une base de données, vous devez suspendre temporairement toute activité de réplication en relation avec la copie du groupe de stockage. Vous pouvez suspendre l'activité de relecture du journal des transactions à l'aide de la cmdlet Suspend-StorageGroupCopy dans l'environnement de ligne de commande Exchange Management Shell. Une fois le contrôle de cohérence terminé, vous pouvez reprendre l'activité de relecture des journaux de transactions à l'aide de la cmdlet Resume-StorageGroupCopy.
Récupération d'un endommagement dans un environnement de CCR
Une réplication continue en cluster (CCR) permet de récupérer suite à un endommagement ou des défaillances d'un groupe de stockage de production en déclenchant une interruption programmée. Si les fichiers journaux ne sont pas endommagés, la récupération n'occasionne normalement aucune perte de données. En revanche, si les fichiers journaux ne sont pas disponibles, la récupération ne peut que ramener le groupe de stockage à un point dans le temps cohérent avec le dernier ensemble de modifications non endommagées que la copie a reçues. Une contrainte supplémentaire est qu'il ne peut pas y avoir de données de changement manquantes ou endommagées antérieures à ce point dans le temps.
Pour obtenir une procédure détaillée expliquant comment récupérer le système suite à une corruption ou des défaillances dans un environnement CCR, consultez les rubriques suivantes :
Restauration d'une CCR suite à une défaillance ou un endommagement
La CCR intègre une fonctionnalité de récupération d'urgence automatique. Il reste néanmoins des cas où une récupération manuelle est requise. Ces cas sont les suivants :
Le fichier de base de données est endommagé sur la copie passive Pour obtenir la procédure détaillée de restauration d'une réplication continue en cluster suite à un endommagement de base de données, consultez la rubrique Procédure de restauration suite à l'endommagement d'une base de données.
La base de données ou un volume du journal est défaillant sur la copie passive Pour obtenir la procédure détaillée de restauration d'une réplication continue en cluster suite à une défaillance du volume, consultez la rubrique Procédure de restauration suite à l'échec d'un volume.
La base de données est défaillante ou divergente La réplication continue en cluster détecte et signale toute divergence de base de données à la suite d'une défaillance. En général, cela se produit quand une copie de la base de données est rendue disponible et que la copie de la base de données défaillant contient un nombre de modifications supérieur à ce qu'autorisent les critères de montage automatique acceptable. Pour obtenir la procédure détaillée de restauration d'une réplication continue en cluster suite à une défaillance ou une divergence de base de données, consultez la rubrique Procédure de restauration de la fonctionnalité de CCR suite à une défaillance ou une divergence.