Réplication locale en continu

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

Dernière rubrique modifiée : 2008-01-17

La réplication continue locale (LCR) est une solution de serveur unique qui utilise une technologie d'envoi des journaux asynchrone et de relecture des journaux intégrée pour créer et conserver une copie d'un groupe de stockage sur un deuxième ensemble de disques qui sont connectés au même serveur que le groupe de stockage de production. Le groupe de stockage de production est appelé copie active, et la copie active du groupe de stockage conservée sur un jeu de disques distinct est appelée copie passive. La figure suivante illustre un déploiement de base de la LCR.

Déploiement de base de la réplication continue locale

La LCR permet l'envoi de journaux, la relecture de journal et un basculement manuel rapide (appelé activation) vers une copie secondaire des données. La LCR est conçue pour minimiser le coût total de possession d' Microsoft Exchange Server 2007 par :

• Elle réduit la durée de récupération suite à des incidents au niveau des données en permettant un basculement rapide vers une copie secondaire en ligne des données.

• Elle réduit le nombre de sauvegardes complètes régulières requises pour la protection des données. Il est essentiel d'effectuer des sauvegardes de données en prévision d'incidents éventuels. Bien que la fonction LCR n'élimine pas la nécessité d'effectuer des sauvegardes, elle réduit la nécessité d'effectuer des sauvegardes quotidiennes complètes.

• vous permet de décharger les sauvegardes VSS (Volume Shadow Copy Service) de la copie active d'un groupe de stockage vers la copie passive du groupe de stockage. Les quatre types de sauvegardes VSS (complète, copie, incrémentielle et différentielle) peuvent être extraits de la copie passive. Le déchargement des sauvegardes de la copie active vers la copie passive conserve les E/S disque importants sur les numéros d'unité logique (LUN) de la copie active.

La LCR permet la configuration, l'opération, la vérification, la suppression et l'activation d'une copie du groupe de stockage. Si nécessaire, il est possible d'activer une copie passive comme base de données de production, de la monter, puis de la rendre disposnible pour les clients. Généralement, vous pouvez exécuter cette tâche comme un changement de configuration, soit en modifiant les chemins d'accès au groupe de stockage actif et à la base de données, soit à l'aide d'une action de niveau inférieur du système d'exploitation (par exemple, modifier les points de montage associés aux volumes de journal ou de base de données).

La LCR n'inclut pas d'exigences de stockage particulières. Vous pouvez utiliser tout type de stockage pris en charge par Windows Server 2003 ou Windows Server 2008 avec la LCR, y compris un stockage DAS, une solution de stockage SAS (Serially Attached SCSI) et une solution iSCSI (Internet SCSI). Pour obtenir la liste des solutions de stockage certifiées, consultez le catalogue Windows Server des produits testés.

La LCR est une option excellente pour les clients qui doivent disposer d'une solution de récupération rapide à la suite d'une défaillance ou d'un endommagement de données de boîte aux lettres mais qui peuvent tolérer des interruptions de serveur pour des raisons programmées ou non programmées. La LCR offre les fonctionnalités suivantes :

• récupération rapide, en deux étapes, suite à un endommagement ou une défaillance d'une base de données de production ;

• protection pour les utilisateurs qui en ont le plus besoin ;

• impact minimal sur la base de données de production et les E/S de disque de journal ;

• possibilité de décharger des sauvegardes VSS sur la copie passive de la base de données et des journaux ;

• possibilité de réduire la quantité totale de données déplacées vers un support de sauvegarde, lors de l'extension de la période de sauvegarde ;

• administration disponible via la console de gestion Exchange ou l'environnement de ligne de commande Exchange Management Shell.

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

Microsoft Exchange Server 2007 Service Pack 1 (SP1) apporte plusieurs améliorations à la LCR, notamment l'utilisation du conteneur de dépôt de transport, 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.

Conteneur de dépôt de transport activé pour la LCR

La fonctionnalité de conteneur de dépôt de transport du rôle serveur de transport Hub a été étendue dans Exchange 2007 SP1 pour prendre en charge la LCR. Dans la version de publication (RTM) de Microsoft Exchange Server 2007, le conteneur de dépôt de transport était uniquement accessible aux environnement de réplication continue en cluster (CCR). Contrairement à la CCR, dans laquelle la demande de nouvelle remise du conteneur de dépôt de transport est une fonction automatique du processus de récupération, dans un environnement LCR, le processus est manuel. Le cmdlet Restore-StorageGroupCopy a été mise à jour dans Exchange 2007 SP1 et inclut la demande de nouvelle remise du conteneur de dépôt de transport. C’est pourquoi, lorsqu’un administrateur active une copie passive d’un groupe de stockage dans un environnement LCR à l’aide de la cmdlet Restore-StorageGroupCopy cmdlet, la demande de nouvelle remise du conteneur de dépôt de transport se produit dans le cadre du processus d’activation.

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é. Une nouvelle fonctionnalité a été ajoutée à la tâche Restore-StorageGroup de sorte que, lorsqu’un administrateur utilise cette tâche pour activer la copie passive du groupe de stockage, le service de réplication Microsoft Exchange demande une nouvelle remise des messages dans le conteneur de dépôt de transport de chaque serveur de transport Hub dans le site du serveur de boîtes aux lettres. La banque d'informations supprime automatiquement les doublons et remet de nouveau les messages perdus.

Dans Exchange 2007 SP1, pour qu'un message électronique se trouve dans le conteneur de dépôt 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 sur un serveur autonome dans un groupe de stockage activé pour la LCR.

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.

Pour obtenir la procédure détaillée pour la configuration des paramètres du conteneur de dépôt de transport, consultez la rubrique Procédure de configuration du conteneur de dépôt de transport pour la réplication continue locale.

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 la LCR. 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.

• Gérer la 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 :

• 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

Améliorations des performances

Plusieurs 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 incluent des réductions d’E/S sur les disques contenant des copies passives des 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 la base de données est à présent conservé pour la copie de groupe de stockage entre des instances de relecture de journaux. La conservation du cache de base de données entre des instances d'activité de relecture du journal permet au service de réplication Microsoft Exchange de tirer partie des 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 disques 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 sur le numéro d’unité logique passif par rapport aux E/S de disque du numéro d’unité logique actif.

Utilisation de la réplication continue de secours avec la LCR

La réplication continue de secours (SCR) est une nouvelle fonctionnalité d’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 de cluster à copie unique (SCC) ou un environnement CCR.

Le processus d’activation des copies des données du serveur de boîtes aux lettres créées et gérées par la SCR est manuel, et son utilisation n’est prévue que lorsqu’une défaillance importante se produit. Le processus n’est pas sensé être utilisé pour de simples interruptions de serveurs récupérables via 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 LCR en relation avec un plan de disponibilité élevée et de tolérance de pannes des données :

• Planification de la réplication locale en continu

• Gestion de la réplication locale en continu

• Procédure de dépannage des problèmes de réplication locale en continu