Réplication continue de secours

 

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

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

La réplication continue de secours (SCR) est une nouvelle fonctionnalité ajoutée au Service Pack (SP1) Exchange Server 2007 de Microsoft. Comme son nom l’indique, la SCR est conçue pour les scénarios utilisant ou activant l’utilisation des serveurs de récupération de secours. SCR étend les fonctionnalités de réplication en continu existantes dans la version de publication (RTM) d’ Exchange Server 2007 et active de nouveaux scénarios de disponibilité pour les serveurs de boîtes aux lettres qui exécutent SP1. La SCR utilise la technologie d’envoi et de relecture des journaux utilisée par la réplication continue locale (LCR) et la réplication continue en cluster (CCR) afin de fournir des options et configuration de déploiement supplémentaires.

SCR permet de séparer la disponibilité élevée (constituée par la disponibilité des données et services) et la résilience de site. Par exemple, la SCR peut être alliée à la CCR pour répliquer localement des groupes de stockage dans un centre de données principal (qui utilise la CCR pour une disponibilité élevée) et à distance dans un centre de données secondaire ou de sauvegarde (qui utilise la SCR pour la résilience de site). Ce centre de données secondaire pourrait contenir un nœud passif dans un cluster de basculement qui héberge les cibles de SCR. Ce genre de cluster s’appelle un cluster de secours parce qu’il ne contient aucun serveur de boîtes aux lettres en cluster, mais qu’il peut être rapidement configuré 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 y être rapidement activées.

Sources et cibles

À l’instar de la LCR et de la CCR, la SCR utilise le concept de copies actives et passives d’un groupe de stockage, mais les appelle plutôt sources et cibles. Ainsi, tout comme la CCR, la SCR nécessite que les chemins de la base de données et des fichiers journaux soient les mêmes dans la source et dans la cible.

Le point de départ de la SCR s'appelle la source, qui peut être n’importe lequel des groupes de stockage de :

• serveur de boîtes aux lettres autonome ;

• serveur de boîtes aux lettres en cluster dans un cluster à copie unique (SCC) ;

• serveur de boîtes aux lettres en cluster dans un environnement de CCR.

  Notes

  Les groupes de stockage de récupération ne peuvent pas être activés pour la SCR.

À l’instar de la LCR et de la CCR, les groupes de stockage SCR ne peuvent contenir plus d’une base de données. Vous ne pouvez pas activer la SCR pour un groupe de stockage qui contient plus d’une base de données, et vous ne pouvez pas ajouter une seconde base de données ou une base de données subséquente à un groupe de stockage SCR.

Si l'ordinateur source de SCR n'est pas regroupé en cluster, il peut également héberger d'autres rôles serveur, tels que les rôles serveur de transport Hub, d'accès au client et de messagerie unifiée.

Le point de terminaison de la SCR s’appelle la cible, et elle peut être :

• un serveur de boîtes aux lettres autonome non activé pour la LCR pour un groupe de stockage ;

• un cluster de secours (cluster de basculement dans lequel le rôle de boîte aux lettres en cluster passif est installé) ; aucun serveur de boîtes aux lettres en cluster (par exemple, aucun rôle de boîtes aux lettres en cluster actif) n'a été installé dans le cluster.

Un ordinateur cible de SCR doit être équipé du rôle de serveur de boîtes aux lettres, même s'il n'héberge pas de boîtes aux lettres de production. Le rôle serveur de boîtes aux lettres est requis parce qu'il inclut le services de réplication Microsoft Exchange et d'autres composants nécessaires à la fonctionnalité de SCR. Si l'ordinateur cible de SCR n'est pas regroupé en cluster, il peut également héberger d'autres rôles serveur, tels que les rôles serveur de transport Hub, d'accès au client et de messagerie unifiée.

La SCR est disponible dans l'édition standard du SP1 Exchange 2007. Si un serveur de boîtes aux lettres dans un environnement SCC ou CCR est utilisé comme source SCR, le SP1 Exchange 2007 Enterprise Edition est nécessaire parce que la mise en cluster de Exchange 2007 nécessite l'Enterprise Edition. Si un cluster de secours est utilisé comme cible SCR, l’Enterprise Edition du SP1 Exchange 2007 est aussi requise.

Comparaison de la SCR avec la LCR et la CCR

Bien que la SCR ressemble à la LCR et à la CCR, elle possède des caractéristiques qui lui sont propres :

• Elle prend en charge de multiples cibles de réplication par groupe de stockage. La LCR et la CCR prennent en charge une seule cible de réplication par groupe de stockage (appelée copie passive).

• La SCR comprend un délai prédéfini pour l’activité de relecture, et l'administrateur peut spécifier un délai supplémentaire. Cette fonctionnalité est précieuse dans plusieurs scénarios. Par exemple, si une corruption logique survient dans une base de données active, les délais prédéfini et défini par l'administrateur peuvent servir à prévenir une telle corruption dans la base de données cible de la SCR. La LCR et la CCR ne proposent pas de délais analogues.

• Il est possible de gérer totalement la SCR depuis le Management Shell de Exchange . La Management Console Exchange peut être utilisée pour gérer de nombreux aspects de la LCR et de la CCR, mais elle ne peut servir ni à activer ni à gérer des aspects de la SCR.

Activation de la copie de SCR

Le processus d'utilisation d'une base de données cible de SCR est appelé activation. Le mode d'activation de la base de données dépend de la nature de la défaillance. Si une ou plusieurs bases de données dans la source de SCR sont affectées, vous pouvez utiliser la fonctionnalité de portabilité des bases de données dans Exchange 2007 dans le cadre du processus d'activation pour les bases de données cibles de SCR. Si toutes les bases de données sur un serveur source de SCR sont affectées, ou si un serveur ou serveur de boîtes aux lettres entier est en cours de récupération, vous pouvez utiliser les fonctionnalités de récupération de serveur du programme d'installation (Setup /m:RecoverServer pour un serveur autonome et Setup /RecoverCMS pour un serveur de boîtes aux lettres en cluster) dans le cadre du processus d'activation.

Notes

Si vos plans de récupération d'urgence incluent l'utilisation de l'option Setup /RecoverCMS pour récupérer un serveur de boîtes aux lettres en cluster (CCR ou SCC) sur lequel un ou plusieurs groupes de stockage sont activés pour la SCR, vous devez d'abord désactiver la SCR pour les groupes de stockage avant d'exécuter l'option Setup /RecoverCMS.

Pour plus d'informations sur l'activation et la récupération d'un environnement de SCR, consultez la rubrique Activation de cibles de réplication continue de secours.

Scénarios de déploiement de la SCR

La SCR vous permet d’utiliser la réplication en continu pour répliquer les données du serveur de boîtes aux lettres depuis un serveur de boîtes aux lettres autonome, ou depuis un serveur de boîtes aux lettres en cluster dans une SCC ou dans un environnement CCR. Les dessins suivants illustrent quelques-unes des possibilités de configuration de la SCR.

Utilisation de la SCR pour répliquer un groupe de stockage depuis un serveur de boîtes aux lettres autonome vers un autre serveur de boîtes aux lettres

Le dessin ci-dessus illustre l’utilisation de la SCR pour répliquer de multiples groupes de stockage depuis un serveur de boîtes aux lettres vers un autre. Dans cet exemple, les serveurs de boîtes aux lettres sont mis en cluster et agissent tous deux comme sources et cibles SCR. Dans cet exemple, chaque serveur se trouve dans un centre de données et un site Active Directory différents. Selon la nature de la défaillance, la récupération d’un groupe de stockage sur l'un des serveurs peut être effectuée à l'aide de la portabilité de base de données ou de l’option d’installation /RecoverServer.

Utilisation de la CCR pour répliquer des groupes de stockage localement et de la SCR pour répliquer un groupe de stockage depuis un emplacement distant

Le dessin ci-dessus montre un modèle de CCR vers SCR, une source et une cible. Dans cet exemple, EXCLUS 1 est un serveur de boîtes aux lettres en cluster dans un environnement CCR qui se situe sur le site REDMOND Active Directory . EXCLUS1DR est un cluster de secours situé sur le site QUINCY Active Directory . Dans ce cas, la récupération de tous les groupes de stockage sur la cible SCR peut être accomplie à l'aide du commutateur d'installation /RecoverCMS . Dans le cas où certains groupes de stockage n’ont pas besoin d’être récupérés, un groupe de stockage ou plus peuvent être récupéré(s) grâce à la portabilité de la base de données.

Utilisation de la CCR pour répliquer des groupes de stockage localement et de la SCR pour répliquer des groupes de stockage vers des emplacements distants

Le dessin ci-dessus montre un modèle de CCR vers SCR, une source et plusieurs cibles. Les ordinateurs de gauche représentent les deux noeuds CCR physiques dans un même centre de données. Les ordinateurs de droite représentent deux cibles SCR dans un autre centre de données. Dans cet exemple, un groupe de stockage unique est répliqué vers de multiples cibles SCR sur deux ordinateurs distincts. La récupération du groupe de stockage sur l’une ou l’autre de ces cibles SCR peut être effectuée selon l'une ou l'autre des méthodes suivantes :

• /RecoverCMS peut être utilisé lors de la récupération de groupes de stockage, seulement depuis une source CCR unique.

• La portabilité de la base de données peut être utilisée pour la récupération de groupes de stockage depuis des sources CCR multiples.

Utilisation de plusieurs cibles de SCR distantes pour un SCC

Le dessin ci-dessus montre un modèle de SCC vers SCR, une source et plusieurs cibles. Les ordinateurs de gauche représentent les deux noeuds SCC physiques dans un seul centre de données. Les ordinateurs de droite représentent deux cibles SCR dans un deuxième centre de données. Dans cet exemple, un seul groupe de stockage est répliqué vers deux cibles autonomes situées dans un deuxième centre de données. La récupération de ce groupe de stockage sur la cible SCR peut être accomplie à l'aide du commutateur d'installation /RecoverCMS .

Mises à jour Cmdlet pour SCR

Il est possible de gérer la SCR depuis le Management Shell de Exchange . SP1 inclut un nouveau paramètre appelé StandbyMachine pour plusieurs cmdlets de l'environnement de ligne de commande Exchange Management Shell utilisées pour la gestion et la configuration de la réplication continue. En particulier, les cmdlets suivantes comprennent désormais la prise en charge de la SCR et le paramètre StandbyMachine :

• Suspend-StorageGroupCopy

• Resume-StorageGroupCopy

• Update-StorageGroupCopy

• Restore-StorageGroupCopy

• Get-StorageGroup

• Get-StorageGroupCopyStatus

En plus des mises à jour de cmdlet précédentes, les cmdlets New-StorageGroup et Enable-StorageGroupCopy cmdlets ont été mises à jour pour prendre en charge la SCR. Dans SP1 Exchange 2007 , vous pouvez utiliser New-StorageGroup pour créer un nouveau groupe de stokage dans lequel la SCR est activée et Enable-StorageGroupCopy pour activer la SCR pour un groupe de stockage existant. Ces cmdlets incorporent les paramètres mis à jour suivants :

• -StandbyMachine   Ce paramètre spécifie le nom de l’ordinateur cible SCR.

• -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). Le réglage par défaut de cette valeur est de 24 heures (1.0:0:0). Le paramètre maximal autorisé pour cette valeur est de 7 jours. Le paramètre minimal autorisé est de 0 secondes, bien que définir cette valeur sur 0 élimine efficacement tout retard dans l’activité de relecture de journal au-delà du délai par défaut 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.

En plus du délai de relecture que l’administrateur a spécifié à l’aide du paramètre ReplayLagTime , Exchange empêchera qu’un nombre fixe de fichiers journaux ne soient relus sur une cible SCR, indépendamment de la valeur de ReplayLagTime qui se sert de la formule Maximum de ("valeur de ReplayLagTime" ou "X fichiers journaux") où X=50. Il s’agit d’une sécurité supplémentaire visant à prévenir la nécessité de réamorçage d’un groupe de stockage si un basculement figé survient dans un environnement de réplication en continu (par exemple, LCR ou CCR) qui fait office de source SCR, et si celle-ci est mise en ligne à l'aide de la cmdlet Restore-StorageGroupCopy . En retardant l'activité de relecture sur les cibles de SCR lors du basculement figé d'une source de SCR, le réamorçage des copies de SCR est réduit puisque la nature de la perte de données sur la source de SCR rapproche les deux copies.

Important :

Le décalage de relecture intégré de 50 fichiers journaux et le délai par défaut de 24 heures sont déterminants pour la création de la base de données initiale de la source SCR. Une base de données cible de SCR n'est créée qu’après que 50 fichiers journaux de transactions ont été répliqués sur l’ordinateur cible de SCR et que la période de temps spécifiée par ReplayLagTime (ou la valeur par défaut de 24 heures) est écoulée.

Mises à jour du réglage pour SCR

La SCR est surtout conçue pour les défaillances majeures, comme une défaillance de site complète. Ces genres de scénarios de défaillance impliquent des activités manuelles, telles l’activation d’un centre de données de sauvegarde, ou le rapatriement vers un centre de données principal.

À l’aide de la figure Utilisation de plusieurs cibles de SCR distantes pour un SCC plus haut dans cette rubrique, examinez ce qu’il advient lorsque le centre de données principal (site contenant le SCC) connaît une défaillance et que la décision est prise d'activer le deuxième centre de données comme site principal de remplacement. Quand le deuxième centre de données est activé, la configuration du centre de données originelle est conservée dans Active Directory, et cette configuration est utilisée par le deuxième centre de données une fois qu'il est activé. La configuration du serveur de boîtes aux lettres en cluster pour la SCC est aussi conservée dans le cluster d'origine. Afin que le cluster d’origine soit remis en ligne, la configuration du serveur de boîtes aux lettres en cluster doit être retirée des nœuds du cluster sans affecter la configuration du serveur de boîtes aux lettres en cluster dans Active Directory (qui est utilisé par le deuxième centre de données).

Pour faciliter cela et d’autres scénarios de résilience de site, l’installation a été modifiée dans SP1 Exchange 2007. En particulier, l’installation comprend une nouvelle option de ligne de commande appelée /ClearLocalCMS, utilisée pour effacer les informations de configuration du serveur de boîtes aux lettres en cluster des noeuds de cluster d'origine sans affecter les informations de configuration stockées dans Active Directory. Par exemple, pour effacer les données de configuration locales d'un serveur de boîtes aux lettres en cluster appelé EXCLUS1, vous devez exécuter la commande suivante localement sur chaque nœud du cluster d'origine duquel vous souhaitez supprimer un serveur de boîte aux lettres en cluster.

Setup /ClearLocalCMS

Vous devez connaître les besoins et restrictions suivants lorsque vous utilisez l’option /ClearLocalCMS :

• Il n'est possible d'utiliser cette option que localement, et pas à distance.

• Cette option ne peut être utilisée que sur les nœuds qui hébergent un serveur de boîte aux lettres en cluster (par exemple, des nœuds actifs) ; elle ne peut pas être utilisée sur des nœuds passifs.

• Cette option ne supprime pas les fichiers programme de Microsoft Exchange , et ne met à jour aucune information de configuration dans Active Directory.

• Cette option ne peut être utilisée que lorsque le serveur de boîtes aux lettres local est hors ligne, et quand le nœud local ne se trouve pas dans la liste des RedundantMachines pour le serveur de boîtes aux lettres local en cluster.

• Les autorisations de l’administrateur du serveur Exchange concernant le serveur de boîtes aux lettres en cluster doivent être déléguées au compte utilisé pour effacer la configuration du serveur de boîtes à lettres local en cluster.

• Si les nœuds de cluster sont exécutés sous Windows Server 2008 après l'exécution de l'option Setup /ClearLocalCMS, l'objet ordinateur virtuel est désactivé. Vous devez le réactiver.

Pour plus d'informations

Pour plus d'informations sur la planification de la SCR, consultez la rubrique Planification de la réplication continue de secours. Pour plus d'informations sur la gestion de la SCR, notamment la procédure détaillée d'activation et de désactivation de la SCR pour un groupe de stockage, consultez la rubrique Gestion de la réplication continue de secours.