Partager via

Gestion de la réplication continue de secours

  • Article

 

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

Dernière rubrique modifiée : 2008-11-19

En plus des tâches relatives à la gestion et l'administration quotidiennes d'une organisation Microsoft Exchange, il y a des tâches spécifiques à la réplication continue de secours (SCR). Généralement, les tâches administratives pour la SCR sont :

  • La configuration du disque de stockage pour SCR et la gestion des volumes de disque.

  • Activation et désactivation de la SCR.

  • analyse de l'activité de réplication ;

  • Montage, démontage, création, et suppression de bases de données.

  • Déplacement de la localisation pour le stockage de fichiers de groupe de stockage ou base de données quand un groupe de stockage à extension SCR.

  • Vérification de la santé de la cible SCR.

  • Gestion de réplication et activité de réinsertion.

  • Récupération après un endommagement.

Ces tâches sont détaillées dans les parties suivantes de cette rubrique.

SCR est activée et gérée uniquement à l'aide d'Exchange Management Shell. La console de gestion d'Exchange ne peut pas être utilisée pour activer ou désactiver SCR, afficher son état ou en gérer tous les aspects.

Configuration de stockage sur disque pour la réplication continue de secours

La SCR ne requiert pas un stockage sur disque spécialement configuré. SCR nécessite un stockage qui fournisse des capacités adéquates. Des solutions de stockage équivalentes peuvent être configurées pour toutes les cibles SCR configurées pour le même groupe de stockage. Il est recommandé de suivre les procédures de configuration fournies par votre fournisseur de solutions de stockage pour effectuer la configuration.

Gestions des volumes de disque dans un environnement SCR

Lors de la gestion d'un environnement de SCR, il peut être nécessaire de gérer des volumes de disque connectés à votre serveur Exchange. Par exemple, le volume peut nécessiter un détachement temporaire du système pour des raisons de maintenance ou autres. Si la maintenance doit être faite sur le volume du disque contenant la copie active du groupe de stockage, la base de données dans la copie active du groupe de stockage doit être démontée. Si la maintenance doit être effectuée sur les volumes du disque contenant la copie passive du groupe de stockage, toutes les E/S du volume doivent être arrêtées par suspension de la réplication. Pour plus d'informations sur la gestion des volumes de disque, consultez la rubrique Procédure de préparation des activités de gestion de disque dans le cadre de l'utilisation de la SCR.

Activation de la réplication continue de secours

La SCR n'est activée que par l'utilisation de l'environnement de ligne de commande Exchange Management Shell et l'exécution de la cmdlet New-StorageGroup ou Enable-StorageGroupCopy. Les deux cmdlets incluent de nouveaux paramètres intégrés avec Microsoft Exchange Server 2007 Service Pack 1 (SP1) :

  • -StandbyMachine   Ce paramètre est utilisé pour spécifier le nom de l'ordinateur qui contiendra la cible SCR. La valeur de ce paramètre est définie en tant que partie de la valeur pour l'attribut msExchStandbyCopyMachines du groupe de stockage en cours d'activation pour SCR. L'attribut msExchStandbyCopyMachines est une chaîne Unicode à valeurs multiples ajoutée au schéma du service d'annuaire Active Directory lorsqu' Exchange 2007 SP1 est introduit dans l'organisation Exchange.

  • -ReplayLagTime   Ce paramètre spécifie le temps d’attente du service de réplication Microsoft Exchange avant la relecture des fichiers journaux copiés vers l’ordinateur SCR cible. Le format de ce paramètre est (jours.heures:minutes:secondes). La valeur par défaut de ce paramètre est 24 heures. Le paramètre maximal autorisé pour cette valeur est de 7 jours. Le paramètre minimal autorisé est de 0 secondes. La définition de cette valeur sur 0 secondes n'affecte pas le délai par défaut dans l’activité de relecture de journal de 50 fichiers journaux. Une fois définie, la valeur de ce paramètre ne peut pas être modifiée sans la désactivation puis la réactivation de la SCR.

  • -TruncationLagTime   Ce paramètre spécifie le temps d’attente du service de réplication Microsoft Exchange avant la troncation des fichiers journaux copiés vers l’ordinateur SCR cible et relus dans la copie de la base de données. Le décompte commence une fois le dernier journal relu avec succès dans la copie de la base de données. Le format de ce paramètre est (jours.heures:minutes:secondes). Le paramètre maximal autorisé pour cette valeur est de 7 jours. Le paramètre minimal autorisé est de 0 secondes. La définition de cette valeur sur 0 secondes élimine efficacement tout retard dans l’activité de troncature de journal. Une fois définie, la valeur de ce paramètre ne peut pas être modifiée sans la désactivation puis la réactivation de la SCR.

  • -SeedingPostponed   Ce paramètre peut être utilisé pour ignorer l'amorçage initial de la cible SCR. S'il est utilisé, l'administrateur doit amorcer manuellement la cible SCR à l'aide de la cmdlet Update-StorageGroupCopy. Ce paramètre est disponible avec la cmdlet Enable-StorageGroupCopy uniquement. Il n'est pas disponible avec la cmdlet New-StorageGroup car aucune base de données source n'existe à ce stade.

    Important

    Pour modifier les paramètres de délai de relecture ou de troncature, vous devez commencer par désactiver la SCR, puis la réactiver avec les nouvelles valeurs définies pour ces paramètres.

En plus du délai de relecture configuré par l’administrateur à l'aide du paramètre ReplayLagTime, Exchange empêche également la relecture d'un nombre de fichiers journaux sur une cible SCR, indépendamment de la valeur de ReplayLagTime, à l'aide de la formule suivante :

Maximum de (« valeur de ReplayLagTime » ou « X fichiers journaux »)

où X=50. Il s'agit d'une sécurité supplémentaire par rapport à l'obligation de réamorcer un groupe de stockage lorsqu'une source SCR qui se trouve dans un environnement de réplication continue, par exemple la réplication continue locale (LCR) ou la réplication continue en cluster (CCR), subit un basculement figé et est connectée à l'aide de la cmdlet Restore-StorageGroupCopy. En retardant l'activité de relecture sur les cibles SCR lors du basculement figé d'une source SCR, le réamorçage des copies SCR est réduit puisque la nature de la perte de données sur la source SCR rapproche les deux copies.

importantImportant :
Le délai prédéfini de 50 fichiers journaux et la valeur du paramètre ReplayLagTime affectent la création de la base de données cible de SCR initiale. Une base de données cible de SCR ne sera créée qu’après que 50 fichiers journaux de transactions soient répliqués vers l’ordinateur cible de SCR et que la période de temps spécifiée par ReplayLagTime (ou la valeur ReplayLagTime par défaut de 24 heures) se soit écoulée.

Lorsque vous activez la SCR pour un groupe de stockage, une copie du groupe de stockage (fichiers système, fichiers journaux et fichier de base de données) est automatiquement créée et maintenue sur l'ordinateur cible de SCR à l'aide des mêmes chemins que le groupe de stockage sur la source de SCR.

Une fois SCR activée, il est recommandé de surveiller l'intégrité et l'état de chaque groupe de stockage à l'aide de la cmdlet Test-ReplicationHealth. Pour obtenir la procédure détaillée de l'activation de la SCR, consultez les rubriques Procédure d'activation de la réplication continue de secours pour un groupe de stockage existant et Procédure d'activation de la réplication continue de secours pour un nouveau groupe de stockage.

SCR et troncature de journaux

Étant donné que vous ne pouvez pas effectuer de sauvegardes d'une base de données cible SCR, la troncature de journaux SCR n'est pas basée sur les temps de sauvegarde. Au lieu de cela, elle est déterminée par le point de contrôle sur la source SCR et la valeur du paramètre TruncationLagTime.

Si la source de SCR est un serveur de boîtes aux lettres en cluster (CMS) dans un environnement de CCR, la logique de troncature des journaux comporte la copie et l'inspection par les fichiers journaux de toutes les cibles de SCR. Cela signifie que si une source SCR n'est pas disponible, la troncature de journaux ne se produira pas sur la source SCR même si les sauvegardes sont effectuées.

Dans un environnement de SCR, une cible de SCR désactivée puis réactivée ne doit pas être réamorcée si tous les fichiers journaux requis sont disponibles, en fonction des conditions suivantes :

  • Si l'enregistrement circulaire est activé pour le groupe de stockage, la suppression du journal provoque un réamorçage de la cible de SCR activée en raison de lacunes dans la séquence de journalisation.

  • Une sauvegarde effectuée avec une troncature de fichier journal entraîne un réamorçage pour la cible de SCR réactivée en raison de lacunes dans la séquence de journalisation.

Si les fichiers journaux ne sont pas tronqués via l'un des deux moyens ci-dessus, la désactivation et la réactivation de la SCR ne doivent pas nécessiter de réamorçage. Dans ce cas, les fichiers journaux de la cible de SCR sont supprimés mais seront répliqués à nouveau à partir de la source de SCR.

Si vous envisagez de réactiver à nouveau la cible de SCR désactivée auparavant, il est recommandé de n'effectuer aucune opération de troncature des journaux (par exemple, l'activation de l'enregistrement circulaire ou des sauvegardes de troncature de journaux) avant que la cible de SCR ne soit à nouveau réactivée et que la modification de la configuration pour la réactivation ne se soit répliquée dans Active Directory.

Désactivation de la réplication continue de secours

L'utilisation de la cmdlet Disable-StorageGroupCopy et du paramètre StandbyMachine permet de désactiver SCR. Lors de la désactivation de SCR, veillez à inclure la valeur appropriée pour le paramètre StandbyMachine. Si LCR est également activée sur le groupe de stockage source SCR source et que vous ne placez pas le paramètre StandbyMachine en tant que partie de cette commande, LCR sera désactivée pour le groupe de stockage.

La désactivation de SCR est nécessaire pour modifier la valeur des paramètres ReplayLagTime ou TruncationLogDelay. Ces valeurs ne peuvent pas être modifiées lorsque SCR est activée. C'est pourquoi, pour modifier les paramètres de délai de relecture ou de troncature, vous devez d’abord désactiver la SCR, puis la réactiver à l’aide des nouvelles valeurs pour ces paramètres.

Pour obtenir la procédure détaillée de désactivation de la SCR pour un groupe de stockage, consultez la rubrique Procédure de désactivation de la réplication continue de secours pour un groupe de stockage.

Analyse de l'activité de réplication

Bien que la SCR ne requière pas de contrôle particulier, 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 SCR :

  • Le service de réplication Microsoft Exchange n'est pas en cours d'exécution. Notez que 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 de cible de SCR est en état d'échec.

  • La copie cible SCR est dans un état sain mais elle est en retard en ce qui concerne la copie de journaux.

Vous devez étudier et résoudre au plus vite toutes les alertes ci-dessus générées par Exchange 2007.

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 (LCR, CCR et SCR) 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, 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 s'applique uniquement aux environnements CCR.

État de groupe quorum

Vérifie que le groupe de clusters contenant la ressource quorum est sain. Ce test s'applique uniquement aux environnements CCR.

É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 s'applique uniquement aux environnements CCR.

É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 s'applique uniquement aux environnements CCR.

État de nœud

Vérifie qu'aucun des noeuds du cluster n'est en état de pause. Ce test s'applique uniquement aux environnements CCR.

É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 DNS (Domain Name System) réussi. Ce test s'applique uniquement aux environnements CCR.

État de service de réplication

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

Copie de groupe de stockage suspendue

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

Copie de groupe de stockage en échec

Vérifie s'il existe des copies de groupe de stockage en état d'échec.

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.

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 de SCR. Si le groupe de stockage ou la base de données source de SCR nécessite une reconfiguration ou une maintenance, vous devez arrêter les services interagissant avec les deux copies lorsque l'activité est en cours. 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 n'est plus accessible.

Déplacement de l'emplacement des fichiers de groupe de stockage et de base de données

Vous pouvez modifier l'emplacement d'une base de données dans un groupe de stockage à SCR activée. Un environnement de SCR comprend deux fichiers de base de données, un par copie. Lors du déplacement des fichiers du groupe de stockage ou du fichier de base de données, les emplacements des deux copies doivent être modifiées simultanément.

Notes

Le chemin complet des fichiers du groupe de stockage et du fichier de base de données doit correspondre à la source SCR et à toutes les cibles SCR.

Des procédures similaires s'appliquent à la reconfiguration de l'emplacement des fichiers système et journaux d'un groupe de stockage et des fichiers de base de données dans un environnement de SCR. Pour obtenir la procédure détaillée de déplacement de fichiers journaux et de fichiers système pour un groupe de stockage à extension LCR, consultez la rubrique Procédure de déplacement d'un groupe de stockage dans un environnement de réplication continue de secours. Pour obtenir la procédure détaillée de déplacement de fichiers de base de données dans un environnement de SCR, consultez la rubrique Procédure de déplacement d'une base de données dans un environnement de réplication continue de secours.

importantImportant :
Il n'est pas possible de placer des bases de données à la racine d'un volume.

Affichage des informations d'état

Toutes les analyses et les diagnostics sont effectués à l'aide d'Exchange Management Shell. La console de gestion d'Exchange n'affiche ni l'état de la copie ni toute autre information relative à SCR. Une fois la SCR activée pour un groupe de stockage, vous pouvez utiliser l'environnement de ligne de commande Exchange Management Shell pour afficher les paramètres de configuration spécifiques à la SCR pour le groupe de stockage et sa base de données.

Informations d'état d'une réplication continue de secours

Exchange 2007 publie diverses informations d'état concernant les copies de SCR. Le tableau suivant décrit les informations d'état disponibles pour les groupes de stockage à extension SCR. Pour obtenir la procédure détaillée d'obtention des informations d'état, consultez la rubrique Procédure d'affichage de l'état de la réplication continue de secours.

Notes

Le tableau suivant répertorie les propriétés selon leur ordre d'apparition dans la sortie de la cmdlet Get-StorageGroupCopyStatus.

Informations d'état disponibles pour les groupes de stockage à extension SCR

Propriété Description

Identity

Serveur et nom du groupe de stockage interrogé.

StorageGroupName

Nom du groupe de stockage interrogé.

SummaryCopyStatus

État général actuel de la copie de SCR. Les valeurs possibles sont les suivantes :

  • Non pris en charge   La configuration actuelle ne prend pas en charge la réplication continue.

  • Désactivé   L'ordinateur n'a pas été désigné comme une cible. Si l'ordinateur cible n'a pas encore lu les informations mises à jour dans Active Directory qui le spécifie comme étant un ordinateur cible, il génére un état Désactivé. Si vous avez activé cet ordinateur cible pour SCR mais qu'il génére un état Désactivé, vérifiez que la réplication de Active Directory ne contient ni problèmes ni latence.

  • Échoué   La vérification a échoué (base de données ou journaux étaient incompatibles entre eux), ou le groupe de stockage est incorrectement configuré pour la SCR.

  • Amorçage   Un amorçage de base de données est en cours.

  • Initialisation   Le système se connecte mais la réplication n'a pas encore commencé. Le système reste dans cet état jusqu'à ce qu'un fichier du journal des transactions soit généré.

  • Service Down    Le service de réplication Microsoft Exchange n'est pas en cours d'exécution.

  • Suspendu   Copie du journal de transactions et relecture arrêtées..

  • Synchronisation   Le système a détecté un basculement et corrige toute divergence.

  • Sain   L'état est sain et normal ; aucun élément ne bloque ou n'est bloqué.

Échec

La vérification de la base de données ou des journaux a 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 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

Amorçage en cours. Les valeurs possibles sont True et False.

Suspend

Réplication (et relecture) arrêtée pour la copie passive. Ceci empêche la base de données d’avancer et les journaux d’être copiés. Les valeurs possibles sont True et False.

SuspendComment

Commentaire facultatif de l'administrateur fournissant une raison ou remarque concernant l'arrêt de l'activité de réplication.

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

Plusieurs fichiers du journal des transactions ont été copiés et attendent d'être relus 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 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

Le dernier numéro de génération de journal généré par le groupe de stockage actif et connu de la copie.

LastLogInspected

Dernier numéro de génération de journaux inspecté 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 du groupe de stockage.

LatestFullBackupTime

Heure de la dernière sauvegarde complète.

LatestIncrementalBackupTime

Heure de la dernière sauvegarde incrémentale.

SnapshotBackup

Sauvegarde effectuée à l'aide d'API en continu héritées ou du Service VSS. Les valeurs possibles sont True et False.

Vous pouvez rapidement évaluer la santé d'une copie de SCR en consultant les valeurs SummaryCopyStatus, CopyQueueLength, ReplayQueueLength, et LastInspectedLogTime. Ces propriétés montrent si la copie de SCR fonctionne normalement et si elle est relativement à 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 :

  • La copie demeure en état non intègre pendant un temps significatif.

  • 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.

  • La dernière heure d’inspection du journal n’affiche pas l’heure actuelle. Il existe deux raisons possibles qui peuvent en être la cause : Soit le groupe de stockage n’enregistre que peu de changement, soit le service de réplication est arrêté.

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 de performance Réplication MSExchange .

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 avec succès alors que sa relecture continue à échouer. 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.

Vérification de l'intégrité d'une cible SCR

Si vous utilisez une SCR, il est recommandé de vérifier l'intégrité de chaque copie cible de CCR périodiquement en exécutant un contrôle de cohérence physique par rapport aux fichiers de base de données et fichiers journaux des 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 la vérification en utilisant la version avec ligne de commande de l'outil Service VSS (VSSAdmin.exe) de Microsoft et l'utilitaire de base de données (Eseutil.exe) de Exchange Server. Pour obtenir la procédure détaillée pour l'utilisation de VSSAdmin et 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 de secours.

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 le groupe de stockage. Vous pouvez suspendre l'activité de réplication à 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. Il est recommandé d'effectuer une vérification hors des heures de production et de minimiser la durée de suspension de l'activité de relecture. Ceci parce que la suspension de copie du groupe de stockage retarde toutes les actualisations de la copie de SCR, causant par conséquent la vulnérabilité de l’échec de certains contenus.

Gestion de réplication et de relecture

La gestion de fichier de journal de réplication et de relecture dans un environnement de SCR implique les principales activités suivantes :

  • Arrêt de la réplication de la copie du groupe de stockage

  • Reprise de la réplication de la copie du groupe de stockage

  • Réamorçage d'un groupe de stockage

Arrêt et redémarrage des modifications de la copie d'un groupe de stockage et de ses bases de données

Pour plusieurs raisons, il peut être nécessaire d'arrêter et de redémarrer l'activité de réplication et/ou de relecture du journal des transactions. La réplication du journal de transactions survient lorsque le service de réplication Microsoft Exchange fonctionne, qu'un groupe de stockage a été activé pour la SCR et que la source et la cible de SCR sont opérationnelles. Si la source ou la cible devient indisponible, vous devez arrêter la réplication. En outre, certaines tâches administratives, telles que l'amorçage, nécessitent que vous arrêtiez la réplication pour un groupe de stockage avec SCR activée. Si vous avez besoin d’arrêter tout accès aux fichiers de données d'une copie, vous devez suspendre la réplication.

Il peut parfois être nécessaire de contrôler les activités de la copie de SCR. Cela peut être requis pour effectuer une reconfiguration ou pour résoudre des problèmes de serveur ou de base de données. L’arrêt de relecture du journal est aussi requis pour exécuter une vérification de consistance physique de la cible de SCR. Quand il s’avère nécessaire de contrôler les mises à jour de la copie de la base de données, la réplication doit être arrêtée pour la cible de SCR. La réplication doit également être arrêtée lorsque les journaux de la cible SCR sont manipulés pour une raison quelconque.

Pour plus d'informations sur l'arrêt des modifications de réplication sur les copies de SCR, consultez la rubrique Procédure de suspension des modifications d'une cible de réplication continue de secours. Pour plus d'informations sur le redémarrage des modifications de réplication sur les copies de SCR, consultez la rubrique Procédure de reprise de la réplication vers une cible de réplication continue de secours. Pour plus d'informations sur l'exécution d'un contrôle d'intégrité des journaux de transactions de la copie passive et du fichier de base de données, consultez la rubrique Procédure de vérification d'une copie de réplication continue de secours.

Amorçage et réamorçage d'une copie de groupe de stockage

L'amorçage et le réamorçage d'une copie de groupe de stockage dans un environnement de SCR s'effectuent à l'aide de la cmdlet Update-StorageGroupCopy et du paramètre StandbyMachine (nouveau paramètre ajouté à Exchange 2007 SP1).

Pour obtenir la procédure détaillée d'amorçage et de réamorçage d'une cible de SCR, consultez la rubrique Procédure d'amorçage de la cible de réplication continue de secours.

Récupération suite à un endommagement avec évaluation de l'état de la réplication lors de l'endommagement

Après un échec ou un endommagement d’une copie de base de données, vous devez l’évaluer si vous voulez continuer immédiatement l’opération en utilisant la cible de SCR. La LCR fournit des informations clés pour faciliter cette prise de décision :

  • intégrité de la copie au moment de l’échec ;

  • files d’attente de relecture et de copie au moment de l’échec ;

  • dernière heure d’inspection du journal au moment de l’échec.

Vous pouvez accéder à ces informations à l'aide de la cmdlet Get-StorageGroupCopyStatus. Pour obtenir la procédure détaillée concernant l'obtention de ces informations, consultez la rubrique Procédure d'affichage de l'état de la réplication continue de secours.

Notes

La dernière heure d’inspection du journal fournit des informations sur les changements les plus récents à partir de la source de SCR. Cela permet de détecter des échecs survenant lorsque le service de réplication Microsoft Exchange n'est pas démarré, dans la mesure où les longueurs des files d'attente sont inexactes en cas d'arrêt du service de réplication Microsoft Exchange.

La longueur de la file d’attente de la copie comprend les informations importantes disponibles de la source de SCR au moment de l’échec. Sur la base de ces informations et de votre évaluation de l’heure de récupération de la base de données en échec, vous devez décider si la cible de SCR disponible doit être activée :

  • Si la longueur de la file d’attente de relecture est importante, la récupération peut prendre du temps mais n’est pas un indicateur qu'une perte significative de données sera expérimentée.

  • Si la longueur de la file d’attente de la copie est significative, un nombre important de journaux est perdu. Si la base de données est activée, elle sera restaurée dans une période de temps approximative à celle du dernier journal copié (également fourni par la cmdletGet-StorageGroupCopyStatus).

  • Si le décalage entre la dernière heure d’inspection du journal et l’heure de l’échec est important, cela signifie probablement que le service de réplication Microsoft Exchange s’est arrêté et que d’autres informations de la file d’attente sont inexactes.

    Notes

    En raison de la nature de la SCR ainsi que des latences et des échecs de communication, il est possible que la longueur de file d’attente de copie soit inexacte car l’état actuel de la copie active est mis à jour de manière asynchrone. En général, l’inexactitude est limitée aux activités à environ une minute avant et après l’échec.

    Notes

    Une base de données en échec ne peut pas être utilisée pour amorcer une cible de SCR.