Planification de la 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-09-11

Si le déploiement de la réplication continue de secours (SCR) est similaire au déploiement de la réplication continue locale (LCR), il y a d'importantes différences à prendre en compte. La configuration suivante doit être respectée :

Configuration générale requise pour la réplication continue de secours

Avant d'activer des groupes de stockage pour la SCR, il est recommandé de vous familiariser avec les besoins des sources et cibles de SCR :

• Une source peut avoir plusieurs cibles. Par exemple, une source peut avoir une cible dans le même centre de données qu'elle, et une deuxième cible dans un autre centre de données. Le nombre de cibles possibles pour une source est illimité. Cependant, nous vous conseillons de ne pas en utiliser plus de quatre par source. L'impact sur le serveur source doit être vérifié et prévu en conséquence si plus de quatre cibles sont configurées.

• Chaque cible peut avoir de multiples serveurs sources. Le système source comme le système cible doivent être équipés de SP1 Exchange 2007 . Il peut s'agir de n'importe quel système d'exploitation pris en charge par Exchange 2007 SP1 (par exemple, Windows Server 2008 ou Windows Server 2003). Toutefois, tous les ordinateurs cibles de SCR doivent exécuter le même système d'exploitation que l'ordinateur source de SCR correspondant. L'utilisation de différents systèmes d'exploitation pour une source de SCR et ses cibles (par exemple, lorsque la source de SCR est Windows Server 2003 et la cible de SCR Windows Server 2008, ou vice versa) n'est pas prise en charge.

• L'ordinateur cible de la SCR doit être équipé du rôle serveur de boîtes aux lettres du SP1 Exchange 2007 . Si l'ordinateur cible de SCR est un nœud de cluster, celui-ci doit être un nœud passif (par exemple, le rôle serveur de boîtes aux lettres en cluster est installé) et le cluster ne peut pas contenir de serveur de boîtes aux lettres en cluster.

• Pour utiliser la SCR, vous devez configurer vos chemins d'installation du serveur Exchange plus minutieusement si vous projetez d’utiliser un cluster de secours et la fonctionnalité de récupération du serveur de boîtes aux lettres en cluster (Setup /RecoverCMS) dans le processus d’activation de la cible SCR. Pour utiliser le processus de récupération du serveur, le chemin d'installation du serveur Exchange doit être le même dans l'ordinateur source de la SCR et dans celui cible. Si le serveur Exchange est installé dans %ProgramFiles%\Microsoft\Exchange Server sur l’ordinateur source de la SCR, il doit aussi être installé dans %ProgramFiles%\Microsoft\Exchange Server sur tous les ordinateurs qui seront les cibles SCR du serveur source. Si ces chemins d’installation ne correspondent pas, Setup /RecoverCMS échoue parce que le chemin d'installation dans le Registre ne correspond pas à la valeur de l'attribut msExchInstallPath de l'objet serveur de boîtes aux lettres dans le service d'annuaire Active Directory.

• Si votre processus d'activation inclut la récupération d'un serveur de boîtes aux lettres en cluster, vous devez désactiver la SCR pour tous les groupes de stockage de ce dernier avant d'utiliser l'option Setup /RecoverCMS dans le cadre du processus d'activation. Dans le cas contraire, l'option Setup /RecoverCMS échoue.

• Les chemins d'accès aux groupes de stockage et bases de données dans la source et les cibles de SCR ne doivent pas être en conflit avec les chemins d'accès d'autres groupes de stockage ou bases de données. Vous devez planifier les chemins d'accès aux groupe de stockage et base de données avec soin lorsque vous utilisez la SCR car le chemin d'accès aux groupe de stockage et base de données utilisé par une source de SCR sera utilisé pour la copie des groupe de stockage et base de données sur toutes les cibles de SCR correspondant à la source.

• Les ordinateurs source et cible de SCR doivent figurer dans le même domaine Active Directory mais peuvent se trouver dans le même site Active Directory ou dans des sites différents.

• Chaque ordinateur cible prend en charge jusqu'à 50 cibles de SCR (50 groupes de stockage répliqués) lorsque l'édition Enterprise d'Exchange 2007 est utilisée, et jusqu'à 5 cibles de SCR lorsque l'édition Standard d'Exchange 2007 est utilisée.

Restrictions sur les ordinateurs cibles de la SCR

Lorsqu'un noeud passif ou un serveur de boîtes aux lettres autonome est configuré en tant que cible de SCR, les fonctionnalités suivantes sont bloquées :

• Il n’est pas possible que la LCR soit activée pour un quelconque groupe de stockage sur un serveur de boîtes aux lettres autonome désigné en tant que cible SCR. Le service de réplication Microsoft Exchange n’a pas été conçu ni modifié pour gérer la LCR et la réplication à partir d'une autre source.

• Un noeud passif désigné en tant que cible SCR doit faire partie d’un cluster avec basculement qui n’a aucun serveur de boîtes aux lettres en cluster. Il s'agit du cluster de secours. Pour plus d'informations sur les clusters de secours, consultez la rubrique Disponibilité élevée.

SCR et bases de données de dossiers publics

La SCR et la réplication des dossiers publics sont deux formes très différentes de réplication intégrées dans Exchange. En raison de limites d'interopérabilité entre la réplication continue et la réplication des dossiers publics, si plusieurs serveurs de boîtes aux lettres de l'organisation Exchange ont une base de données de dossiers publics, la réplication des dossiers publics est activée et les bases de données de dossiers publics ne doivent pas être hébergées dans des environnements de SCR.

Les configurations recommandées pour l'utilisation de bases de données de dossiers publics et de la SCR dans votre organisation Exchange sont les suivantes :

• Si vous avez un serveur de boîtes aux lettres unique dans votre organisation Exchange et qu'il s'agit d'un serveur de boîtes aux lettres autonome ou d'un serveur de boîtes aux lettres en cluster dans un SCC, celui-ci peut héberger une base de données de dossiers publics et le groupe de stockage contenant la base de données de dossiers publics peut être activé pour la SCR, à condition que le groupe de stockage ne soit pas activé pour la LCR. Dans cette configuration, il n'y a qu'une seule base de données de dossiers publics dans l'organisation Exchange. Par conséquent, la réplication de dossiers publics est désactivée. Dans ce scénario, la redondance de base de données de dossiers publics est rendue possible grâce à la SCR, qui conserve deux copies de votre base de données de dossiers publics.

• Si vous avez plusieurs serveurs de boîtes aux lettres et qu'un seul d'entre eux contient une base de données de dossiers publics, qu'il s'agit d'un serveur de boîtes aux lettres autonome ou d'un serveur de boîtes aux lettres en cluster dans un SCC, celui-ci peut héberger une base de données de dossiers publics et le groupe de stockage contenant la base de données de dossiers publics peut être activé pour la SCR, à condition que le groupe de stockage ne soit pas activé pour la LCR. Dans cette configuration, il n'y a qu'une seule base de données de dossiers publics dans l'organisation Exchange. Par conséquent, la réplication de dossiers publics est désactivée. Dans ce scénario, la redondance de base de données de dossiers publics est également rendue possible grâce à la SCR.

• Si vous procédez à la migration de données de dossiers publics vers un groupe de stockage activé pour la LCR, vous pouvez utiliser la réplication de dossiers publics pour déplacer le contenu d'une base de données de dossiers publics d'un serveur de boîtes aux lettres autonome ou serveur de boîtes aux lettres en cluster dans un SCC vers le groupe de stockage activé pour la SCR. Une fois la réplication effectuée, toutes les bases de données de dossiers publics en dehors des groupes de stockage activés pour la SCR doivent être supprimées. Vous ne devez pas héberger d'autres bases de données de dossiers publics dans l'organisation Exchange.

• Si vous procédez à la migration de données de dossiers publics vers un groupe de stockage activé pour la SCR, vous pouvez utiliser la réplication de dossiers publics pour déplacer le contenu d'une base de données de dossiers publics du groupe de stockage vers un serveur de boîtes aux lettres autonome ou serveur de boîtes aux lettres en cluster dans un SCC. Lorsque la réplication est terminée avec succès, toutes les bases de données de dossiers publics dans les groupes de stockage de SCR doivent être supprimées et toutes les bases de données de dossiers publics subséquentes ne doivent pas être hébergées dans des groupes de stockage activés pour la SCR.

Lors des périodes dans lesquelles plusieurs bases de données de dossiers publics existent dans l'organisation Exchange et une ou plusieurs bases de données de dossiers publics sont hébergées dans un groupe de stockage activé pour la SCR, si une défaillance du groupe de stockage source de SCR survient et que la base de données de dossiers publics cible de SCR doit être activée, elle peut devenir montable uniquement si tous les journaux du groupe de stockage hébergeant la base de données de dossiers publics sont disponibles. Si des journaux sont manquants ou indisponibles en raison de la défaillance de la source de SCR, vous ne serez pas en mesure d'activer la copie cible de SCR de la base de données de dossiers publics. Dans ce cas, la source de SCR doit être mise en mode connexion pour garantir qu'il n'y a aucune perte de données ou la base de données de dossiers publics doit être recréée sur la source de SCR et son contenu doit être récupéré à l'aide de la réplication de dossiers publics à partir d'une base de données de dossiers publics autre que la copie cible de SCR.

SCR et sauvegardes

Vous ne pouvez pas sauvegarder une copie de la cible SCR. La LCR et la CCR prennent toutes deux en charge des sauvegardes des copies active comme passive. La SCR prend en charge des sauvegardes seulement pour la source SCR. Les en-têtes de base de données de la cible SCR seront mises à jour et les fichiers journaux seront tronqués quand une sauvegarde prise en charge est faite contre le groupe de stockage de la source SCR. Si ce groupe est activé pour la CCR et la LCR, les en-têtes de base de données de la cible SCR seront mis à jour et les fichiers journaux seront tronqués quand des sauvegardes seront effectuées contre les copies active et passive du groupe de stockage de la source SCR.

SCR et restaurations

Lorsqu'une base de données source de SCR est remplacée par une version antérieure de la base de données, vous devez suspendre puis reprendre la réplication continue pour le groupe de stockage à l'aide des cmdlets Suspend-StorageGroupCopy et Resume-StorageGroupCopy, respectivement. Ce processus est requis pour mettre à jour le service de réplication de Microsoft Exchange avec les informations correctes de génération de journaux. Si la réplication continue n'est pas suspendue et reprise, le service de réplication disposera d'informations de génération de journaux obsolètes et arrêtera la réplication des fichiers journaux.

Troncature de la SCR et du fichier journal

Dans la RTM Exchange 2007 , les règles sont améliorées afin que, dans un environnement de réplication continue, un fichier journal ne soit pas supprimé à moins d'avoir été sauvegardé et relu dans la copie de la base de données. Cette règle change lors de l’utilisation de la SCR. La SCR (qui introduit le concept de copies multiples de bases de données) permet aux fichiers journaux d’être tronqués à la source SCR dès qu’ils ont été inspectés par tous les ordinateurs cibles de la SCR. Pour la troncature des journaux de la source SCR, il n’est pas nécessaire d’attendre jusqu'à ce que ces derniers aient été relus dans toutes les sources SCR parce que les copies cibles de SCR peuvent être configurées avec d'importants délais de relecture de journal. Toutefois, la troncature de journaux sur une source de SCR ne survient pas si une ou plusieurs cibles de SCR pour un groupe de stockage sont arrêtées. Pour que les journaux soient tronqués sur une source de SCR, le ou les ordinateurs cibles de SCR doivent être en ligne et accessibles par la source.

Sur une cible de SCR, un thread en tâche de fond s'exécute toutes les trois minutes pour déterminer si des fichiers journaux doivent être tronqués. Si les trois critères suivants sont remplis, un fichier journal est tronqué sur une cible de SCR :

• Le fichier journal a été tronqué sur la source de SCR.

• La séquence de génération du fichier journal est inférieure au point de contrôle du fichier journal pour le groupe de stockage.

• Le fichier journal est plus ancien que ReplayLagTime + TruncationLagTime. (Pour une description de ces paramètres, consultez la section « Mises à jour des cmdlets pour la SCR » dans la rubrique Réplication continue de secours).

Dans un environnement de LCR ou de CCR étendu avec la SCR, si les trois critères suivants sont remplis, un fichier journal est tronqué sur les copies active et passive de l'environnement de LCR ou de CCR :

• Le fichier journal a été sauvegardé.

• La séquence de génération du fichier journal est inférieure au point de contrôle du fichier journal pour le groupe de stockage.

• Toutes les cibles de SCR ont inspecté le fichier journal.

Optimisation du réseau Windows 2003 pour la SCR

Bien que des optimisations de réseau soient nécessaires lors de l'utilisation de la SCR sous Windows Server 2008, dans le cadre d'une utilisation sous Windows Server 2003, il est recommandé d'optimiser les paramètres TCP/IP de Windows Server afin d'améliorer la vitesse et la latence de votre liaison réseau spécifique. En particulier, vous pouvez ajuster la taille de fenêtre de réception TCP (Transmission Control Protocol) et les options de mise à l'échelle de la fenêtre RFC (Request for Comments) 1323 sur un ordinateur source de SCR et ses ordinateurs cibles. Par ailleurs, il peut s'avérer utile de configurer les paramètres d'expiration de cache du protocole ARP (address resolution protocol) et de désactiver les options TCP/IP avancées pour Windows Server 2003 Scalable Networking Pack (SNP) dans le Registre Windows.

Outre ces recommandations, si votre environnement inclut l'utilisation du protocole IPsec (IP Security), il est recommandé de configurer celui-ci de façon homogène dans votre environnement de SCR. La source de SCR et ses cibles doivent utiliser le protocole IPsec ou ni la source de SCR ni ses cibles ne doivent l'utiliser. Si un seul nœud est configuré pour utiliser le protocole IPsec, le processus Association de sécurité IPsec peut entraîner le retard ou la perte de paquets.

Fenêtres de réception TCP et options de mise à l'échelle RFC 1323

La taille de fenêtre de réception TCP correspond à la quantité de données maximale (en octets) qui peut être reçue en une fois sur une connexion. L'ordinateur d'envoi peut envoyer uniquement cette quantité de données maximale avant d'attendre un accusé de réception et une mise à jour de la fenêtre TCP de l'ordinateur de réception. Il peut être utile d'ajuster ce paramètre afin d'augmenter le débit lors de l'expédition des journaux.

Pour optimiser le débit TCP, l'ordinateur d'envoi doit transmettre suffisamment de paquets pour remplir le canal entre l'expéditeur et le destinataire. La capacité du canal réseau est basée sur la bande passante et la latence (temps de parcours circulaire) du canal. Plus la latence est élevée, plus la capacité est grande, car il y a davantage de temps pour l'envoi des données entre les accusés de réception. L'augmentation de la taille de fenêtre TCP permet au système de profiter du délai entre les accusés de réception pour envoyer davantage de données.

Le standard TCP/IP autorise une taille de fenêtre de réception de 65 535 octets, ce qui correspond à la valeur maximale pouvant être spécifiée dans le champ de taille de fenêtre TCP 16 bits. Pour optimiser les performances sur les réseaux à bande passante élevée et délais importants, les paramètres TCP/IP de Windows Server prennent en charge la possibilité d'annonce de tailles de fenêtre de réception supérieures à 65 535 octets, à l'aide de fenêtres mises à l'échelle comme décrit par le standard RFC 1323, TCP Extensions for High Performance. Lorsque vous utilisez la mise à l'échelle des fenêtres, les hôtes dans une conversation peuvent négocier une taille de fenêtre qui autorise la mise en attente de plusieurs paquets volumineux, tels que ceux généralement utilisés dans les protocoles de transfert de fichiers, au niveau des tampons du destinataire. Le standard RFC 1323 décrit une méthode de prise en charge des tailles de fenêtre de réception élevées en autorisant le protocole TCP à négocier un facteur de mise à l'échelle pour la taille de fenêtre lors de l'établissement de la connexion.

Vous pouvez optimiser la taille de réception TCP et les options de mise à l'échelle RFC 1323 sur un ordinateur exécutant Windows Server 2003 en modifiant les entrées de Registre TCPWindowSize et TCP1323Opts. Pour plus d'informations sur ces fonctionnalités, consultez l'article 224829 de la Base de connaissances Microsoft, Description des fonctionnalités TCP de Windows 2000 et Windows Server 2003.

Il est recommandé d'utiliser la version 13 ou une version ultérieure du calculateur des besoins en stockage du rôle serveur de boîtes aux lettres Exchange 2007 pour déterminer les paramètres optimaux pour ces entrées de Registre en fonction de la liaison et de la latence de votre réseau. Pour télécharger le calculateur, consultez l'article du blog de l'équipe Exchange Calculateur des besoins en stockage du rôle serveur de boîtes aux lettres Exchange Server 2007. Le calculateur de stockage inclut également des instructions détaillées sur la saisie de valeurs de Registre sur vos serveurs.

Expiration du cache ARP

Le cache ARP est une table interne à la mémoire qui établit des correspondances entre des adresses IP et des adresses MAC (media access control). Les entrées dans le cache ARP sont référencées chaque fois qu'un paquet sortant est envoyé à l'adresse IP dans l'entrée. Par défaut, Windows Server 2003 ajuste la taille du cache ARP automatiquement pour répondre aux besoins du système. Si une entrée n'est pas utilisée par un datagramme sortant pendant deux minutes, l'entrée est supprimée du cache ARP. Les entrées référencées sont supprimées du cache ARP après dix minutes. Les entrées ajoutées manuellement ne sont pas supprimées du cache automatiquement.

Le test interne conduit par le département informatique interne de Microsoft a montré que les paramètres d'expiration du cache ARP entraînaient une perte de paquets dans les environnements de CCR et de SCR. En cas de perte de paquets, le serveur d'envoi doit transmettre à nouveau les données perdues. Dans un environnement de réplication continue, il convient de copier les fichiers journaux sur le nœud passif dès que possible. La nouvelle transmission des données perdues en raison des paquets perdus peut affecter le débit de l'expédition des journaux.

Vous pouvez modifier le paramètre TCP/IP ArpCacheMinReferencedLife dans le Registre Windows pour contrôler l'expiration du cache ARP. Ce paramètre détermine le délai de conservation des entrées référencées dans la table du cache ARP avant leur suppression. En interne, Microsoft a identifié que le paramétrage optimal pour la valeur de Registre ArpCacheMinReferencedLife consiste à utiliser la même valeur utilisée pour l'expiration du cache ARP par les routeurs sur le réseau (soit 4 heures).

Avant de modifier la valeur ArpCacheMinReferencedLife dans votre environnement, il est recommandé d'utiliser Microsoft Network Monitor ou un outil de capture similaire pour collecter et analyser le trafic réseau dans l'interface réseau utilisée pour copier les journaux du nœud actif vers le nœud passif. Pour obtenir la procédure détaillée de modification de la valeur de Registre ArpCacheMinReferencedLife, consultez l'annexe A sur les paramètres de configuration TCP/IP.

Fonctionnalités TCP/IP avancées de Scalable Networking Pack

Windows Server 2003 Scalable Networking Pack (SNP) est une mise à jour distincte pour Windows Server 2003 qui contient des déchargements dynamiques et sans état pour accélérer la pile de mise en réseau Windows. La mise à jour inclut le déchargement TCP Chimney, la mise à l'échelle côté réception (RSS, Receive Side Scaling) et l'accès direct à la mémoire réseau (NetDMA, Network Direct Memory Access).

TCP Chimney est un déchargement dynamique. Il permet le déchargement du traitement TCP/IP vers des cartes réseau qui peuvent gérer le traitement TCP/IP pour le matériel.

La mise à l'échelle côté réception et l'accès direct à la mémoire réseau sont des déchargements sans état. Lorsque plusieurs UC résident sur un ordinateur unique, la pile de mise en réseau Windows limite le traitement du protocole de réception vers une UC unique. La mise à l'échelle côté réception résout ce problème en permettant l'équilibrage des paquets reçus d'une carte réseau entre plusieurs UC. L'accès direct à la mémoire réseau inclut un moteur d'accès direct à la mémoire sur le bus PCI (Peripheral Component Interconnect). La pile TCP/IP peut utiliser ce moteur pour copier les données plutôt que d'interrompre l'UC et gérer l'opération de copie. Le composant associé TCPA est une autre fonction de déchargement pour laquelle un moteur matériel d'accès direct à la mémoire sur le bus PCI peut être utilisé pour assister le traitement de réception.

Si ces fonctionnalités peuvent apporter des avantages en termes de performances du réseau dans certains environnement, certains scénarios ne permettent pas de les utiliser en raison de l'utilisation d'autres technologies. Par exemple, le déchargement TCP Chimney et l'accès direct à la mémoire réseau ne peuvent pas être utilisés avec les technologies suivantes :

• Pare-feu Windows ;

• Protocole IPSec (Internet Protocol security) ;

• Traduction d'adresses réseau IP (IPNAT, Internet Protocol Network Address Translation) ;

• pare-feu tiers ;

• lecteurs intermédiaires NDIS 5.1.

Par ailleurs, il y a des problèmes connus dans certains environnements, notamment les environnements incluant Microsoft Exchange, dans lesquels l'utilisation de ces fonctionnalités peut diminuer les performances réseau. Pour plus d'informations sur ces problèmes, consultez l'article de l'équipe Exchange sur Windows 2003 Scalable Networking pack et les effets possibles sur Exchange.

Il est recommandé de désactiver toutes les fonctionnalités dans les environnements de SCR exécutés sous le système d'exploitation Windows Server 2003 pour le système d'exploitation et chaque carte d'interface réseau (NIC) dans le système. Vous pouvez désactiver ces fonctionnalités comme suit :

• Pour désactiver la fonctionnalité de déchargement TCP Chimney, ouvrez une fenêtre d'invite de commandes, puis exécutez la commande suivante : Netsh int ip set chimney DISABLED

• Pour désactiver les autres fonctionnalités SNP, vous pouvez définir les valeurs des paramètres TCP/IP de Registre EnableRSS et EnableTCPA sur 0 dans le Registre Windows. Pour obtenir la procédure détaillée, consultez l'article 936594 de la Base de connaissances sur les problèmes de réseau éventuels après l'installation de Windows Server 2003 SP2 ou de Scalable Networking Pack sur un ordinateur Windows Server 2003.

• Pour désactiver ces fonctionnalités sur la ou les cartes d'interface réseau (NIC) dans le système, consultez les instructions jointes à la carte ou consultez votre fournisseur de matériel.

Pour plus d'informations sur Scalable Networking Pack, consultez l'article 912222 de la Base de connaissances Microsoft sur Microsoft Windows Server 2003 Scalable Networking Pack et le site Web sur l'initiative Scalable Networking.