Planification 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 : 2008-07-23

Si le déploiement de la réplication continue en cluster (CCR) est similaire au déploiement de la réplication continue locale (LCR) et d'un cluster à copie unique (SCC), il y a d'importantes différences à prendre en compte. Certaines configurations sont requises pour CCR. Les configurations de matériel, de logiciel, de réseau et de cluster doivent également être remplies.

Configuration générale requise pour la réplication continue en cluster

Avant de déployer la CCR, assurez-vous que la configuration requise suivante est respectée :

  • Une seule base de données doit être utilisée par groupe de stockage. Lors de la création d'un groupe de stockage dans un environnement CCR, ce groupe ne peut contenir qu'une seule base de données. Cette approche crée une topologie de stockage Microsoft Exchange plus gérable qui augmente les possibilités de récupération.

  • Un serveur DNS (Domain Name System) doit être exécuté. Idéalement, le serveur DNS doit accepter des mises à jour dynamiques. S'il ne les accepte pas, vous devez créer un enregistrement (A) d'hôte DNS pour chaque serveur de boîtes aux lettres en cluster et un autre pour le cluster proprement dit. Dans le cas contraire, Exchange ne fonctionne pas correctement. Pour plus d'informations sur la configuration de DNS pour Exchange, consultez l'article 322856 de la Base de connaissances Microsoft sur la configuration de DNS pour une utilisation avec Exchange Server.

  • Si les noeuds de votre cluster font partie d'une zone DNS (Directory Naming Service) qui ne porte pas le nom de domaine du service d'annuaire Active Directory auquel s'est joint l'ordinateur, par défaut, la propriété DNSHostName n'inclut pas le nom du sous-domaine. Dans ce cas, vous pouvez être amené à modifier la propriété DNSHostName pour vérifier le bon fonctionnement de certains services, tels que le service de réplication de fichiers (FRS, File Replication Service). Pour plus d'informations, consultez l'article 240942 de la Base de connaissances expliquant que la propriété DNSHostName d'Active Directory n'inclut pas de sous-domaine.

  • Tous les noeuds de cluster doivent être des serveurs membres du même domaine. Microsoft Exchange Server 2007 n'est pas pris en charge sur les nœuds qui sont également des serveurs Active Directory, ou sur des nœuds qui sont des membres de différents domaines Active Directory.

  • Le cluster doit être formé avant l'installation d'Exchange 2007. Pour plus d'informations sur la formation d'un cluster avec basculement Windows Server 2008, consultez la rubrique Installation de la réplication continue en cluster sur Windows Server 2008. Pour plus d'informations sur la formation d'un cluster avec basculement Windows Server 2003, consultez la rubrique Installation d'un cluster à copie unique.

  • Les noms de serveur de boîtes aux lettres en cluster (CMS) ne doivent pas comporter plus de 15 caractères.

  • Le cluster dans lequel Exchange 2007 est installé ne peut pas contenir Exchange Server 2003, Exchange 2000 Server ou une version quelconque de Microsoft SQL Server prenant en charge les clusters . L'exécution d'Exchange 2007 dans un cluster avec une de ces autres applications n'est pas prise en charge. L'exécution de Exchange 2007 sur un cluster avec SQL Server 2005 Édition Express ou une autre application de base de données (telle que Microsoft Office Access) est autorisée à condition que l'application de base de données ne soit pas configurée en clusters.

  • Avant d'installer Exchange 2007, vérifiez que le dossier dans lequel vous installerez les données Exchange est vide.

  • Vous devez installer la même version d'Exchange 2007 sur tous les noeuds d'un cluster qui sont configurés comme hôtes d'un serveur de boîtes aux lettres en cluster. En outre, le système d'exploitation et les fichiers Exchange doivent être installés aux mêmes emplacements et sur les mêmes lecteurs pour tous les noeuds du cluster. Cela requiert que tous les ordinateurs aient une configuration de disque similaire mais pas forcément identique.

  • Le compte de service de cluster doit être membre du groupe Administrateurs local sur chaque noeud capable d'héberger un serveur de boîtes aux lettres en cluster.

  • Ne pas installer, créer ou déplacer des ressources du groupe du cluster par défaut vers le groupe de ressources contenant le serveur de boîte aux lettres en cluster. En outre, ne pas installer, créer ou déplacer des ressources du groupe contenant le serveur de boîte aux lettres en cluster vers le groupe de cluster par défaut. Le groupe de cluster par défaut ne doit contenir que l'adresse IP, le nom du réseau et les ressources quorum. Le déplacement ou la combinaison de ressources vers ou avec le groupe de cluster par défaut ne sont pas pris en charge.

    Important

    Les clusters exécutant des versions antérieures d'Exchange nécessitent une instance en cluster de MSDTC (Microsoft Distributed Transaction Coordinator). Exchange 2007 supprime la nécessité de la ressource MSDTC en cluster. Il n'est pas utile que la ressource MSDTC en cluster soit installée dans un cluster de basculement pour les serveurs de boîtes aux lettres en cluster dans un environnement de CCR. Il se peut que les applications tierces nécessitent une ressource MSDTC en raison des dépendances COM+. Dans Windows Server 2003, la ressource de cluster MSDTC requiert l'utilisation d'un stockage partagé dans le cluster. Il n'est pas recommandé d'ajouter un stockage partagé dans un environnement de CCR. Windows Server 2008 fournit une instance MSDTC locale, dans un environnement sans cluster, qui supprime la nécessité d'un stockage partagé dans un cluster de basculement Windows Server 2008. Pour plus d'informations sur les modifications apportées à MSDTC dans Windows Server 2008, consultez l'Aide Windows Server 2008.

Configuration matérielle requise pour la réplication continue en cluster

Pour des informations générales sur la planification du matériel, consultez les rubriques Planification des configurations de processeur et Planification du stockage sur disque. La configuration matérielle requise pour les environnements CCR est la suivante :

  • En cas d'utilisation du quorum jeu de nœud majoritaire (MNS) avec le témoin de partage de fichiers sur Windows Server 2003, il ne peut y avoir que deux nœuds dans le cluster. S'il existe plusieurs nœuds dans un cluster, le quorum jeu de noeud majoritaire avec la fonction de témoin de partage de fichiers est inutilisable. À la place, un quorum jeu de noeud majoritaire traditionnel, avec au moins trois noeuds dans le cluster, doit être utilisé.

  • Lorsque vous utilisez le quorum de noeuds et de partages de fichiers majoritaire sur Windows Server 2008, il ne peut y avoir que deux nœuds dans le cluster. S'il existe plusieurs nœuds dans un cluster, le quorum de noeuds et de partages de fichiers majoritaire est inutilisable. À la place, un quorum de noeuds majoritaire, avec au moins trois noeuds dans le cluster, doit être utilisé.

    Notes

    Il est recommandé d'utiliser un cluster de basculement à deux nœuds qui utilise le quorum jeu de nœud majoritaire avec la fonction de témoin de partage de fichiers ou le quorum de nœuds et de partages de fichiers majoritaire. Il n'est ainsi plus nécessaire d'avoir un troisième nœud votant dans le cluster.

  • Les serveurs utilisés doivent figurer dans le catalogue Microsoft Windows Server des produits testés pour le système d'exploitation sur lequel ils seront installés. Toutefois, si le stockage partagé n'est pas utilisé dans le cluster, les serveurs ne doivent pas figurer dans la catégorie de cluster.

  • Les deux serveurs qui hébergent des rôles serveur de boîtes aux lettres doivent être comparables, mais pas identiques sur les plans suivants :

    • UC

    • Mémoire

    • Fonctionnalité d'entrée/sortie (E/S)

    • Réseau

    • Fournisseur

    • Mémoire disque disponible qui inclut l'espace et les fonctionnalités d'opérations d'E/S

Configuration de quorum requise pour la réplication continue en cluster

Généralement, les applications mises en cluster ne connaissent pas le type de quorum utilisé par le cluster sur lequel elles sont installées. Lors de la conception du composant quorum pour votre environnement CCR, vous devez prendre en compte les recommandations et exigences suivantes :

  • Sur Windows Server 2008, un quorum de noeuds et de partages de fichiers majoritaire est le type de quorum fortement recommandé pour CCR.

  • Sous Windows Server 2003, un quorum jeu de nœud majoritaire avec témoin de partage de fichiers est le type de quorum fortement recommandé pour la CCR.

Si l'un des précédents types de quorum est utilisé pour CCR, il n'est pas nécessaire que les nœuds figurent dans le catalogue Microsoft Windows Server des produits testés.

Si un quorum de stockage partagé est utilisé pour CCR, tout le système doit figurer dans le catalogue Microsoft Windows Server des produits testés.

Dans Exchange Server 2007 Service Pack 1 (SP1), le programme d'installation bloque les configurations de cluster à deux nœuds si un témoin de partage de fichiers ou une majorité de partage de fichiers n'est pas configuré. Cela est dû au fait que la configuration ne pourrait pas gérer la perte d'un nœud dans le cluster (car la majorité ne serait pas maintenue), ce qui provoque une déconnexion du cluster.

Configuration logicielle requise pour la réplication continue en cluster

La configuration logicielle requise pour les environnements CCR est la suivante :

  • Le système d'exploitation Windows Server 2008 Enterprise Edition ou le système d'exploitation Windows Server 2003 Enterprise doit être installé sur chaque nœud du cluster et utiliser les mêmes lettres pour les lecteurs de démarrage et système. Vous ne pouvez pas avoir un cluster avec un noeud exécutant Windows Server 2008 et l'autre noeud exécutant Windows Server 2003. Le mélange de versions de système d'exploitation dans un cluster de basculement n'est pas pris en charge.

  • Si vous développez un environnement de CCR à l'aide de la version de publication (RTM) d'Exchange 2007 sous Windows Server 2003, Windows Server 2003 Service Pack 2 (SP2) ou Windows Server 2003 SP1 et le correctif de l'article 921181 de la Base de connaissances sur la mise à jour qui permet d'ajouter des fonctionnalités de témoin de partage de fichiers et de pulsations de cluster configurable aux clusters de serveur Windows Server 2003 Service Pack 1 doivent être installés sur les deux noeuds dans le cluster de basculement. Le correctif est inclus dans Windows Server 2003 SP2. Si vous développez un environnement de CCR à l'aide d' Exchange 2007 SP1 sous Windows Server 2003, Windows Server 2003 SP2 doit être installé sur les deux nœuds dans le cluster de basculement.

  • Le cluster doit être soit un cluster à trois noeuds avec un quorum MNS classique, soit un cluster à deux noeuds avec un quorum MNS et un témoin de partage de fichiers. En général, cela suppose que sur Windows Server 2003, un cluster à deux nœuds utilisant un quorum MNS avec un témoin de partage de fichiers est utilisé et que sur Windows Server 2008, un cluster à deux nœuds avec un quorum de noeuds et de partage de fichiers majoritaire est utilisé.

  • Le témoin de partage de fichiers pour le quorum MNS ou le quorum de partages de fichiers majoritaire ne doit pas nécessairement se trouver sur un ordinateur dédié. Il peut se trouver sur tout ordinateur exécutant Windows Server. Il est toutefois recommandé d'héberger le témoin de partage de fichiers sur un serveur de transport Hub (ou un autre serveur Exchange) afin qu'il soit placé sous le contrôle de l'administrateur Exchange.

  • Seul le rôle serveur de boîtes aux lettres peut être installé dans un cluster. Aucun autre rôle serveur ne peut être installé sur un ordinateur faisant partie d'un cluster de basculement.

Configuration réseau requise pour la réplication continue en cluster

Il est important de configurer correctement les réseaux utilisés pour les communications des clients et du cluster. Cette section fournit des liens vers les procédures nécessaires pour vérifier si les paramètres relatifs aux réseaux privé et public sont correctement configurés. En outre, vous devez vous assurer que l'ordre des connexions réseau est configuré correctement pour le cluster. Prenez en compte les informations suivantes lors de la conception de l'infrastructure réseau pour votre environnement CCR :

  • Chaque noeud doit avoir au moins deux cartes réseau disponibles pour les clusters Windows. Les clients et les autres serveurs doivent uniquement pouvoir accéder aux noeuds à partir d'une des deux cartes réseau. Les autres cartes réseau sont utilisées pour la communication à l'intérieur d'un cluster. La configuration recommandée consiste à utiliser le réseau privé pour les communications internes du cluster et désigner le réseau public comme mixte.

  • Le réseau public en cluster doit offrir une connectivité à d'autres serveurs et services Exchange, tels que Active Directory et DNS. Vous pouvez empêcher les points de défaillance uniques en utilisant une collaboration de cartes réseau ou une technologie similaire.

  • Un réseau privé en cluster distinct doit être fourni. Le réseau privé est utilisé pour les pulsations de cluster. Le réseau privé ne requiert pas de DNS.

  • La configuration d'interrogation peut ne pas être la configuration de bande passante et de latence réseau public la plus stricte pour une configuration à deux centres de données. Vous devez évaluer la charge totale du réseau, qui inclut l'accès au client, Active Directory, le transport, la réplication continue et autre trafic pour déterminer la configuration réseau nécessaire pour votre environnement.

  • Il est recommandé d'utiliser Gigabit Ethernet pour les environnements CCR afin de maximiser le temps de réamorçage. Pour plus d'informations sur la raison pour laquelle Gigabit Ethernet est recommandé, consultez la section « Taille de base de données et réplication continue en cluster », plus loin dans cette rubrique.

  • Dans la version de publication (RTM) d'Exchange 2007, un groupe de ressources qui contient un serveur de boîtes aux lettres en cluster ne peut avoir qu'une seule ressource de nom de réseau. Exchange 2007 RTM ne prend pas en charge plusieurs ressources de nom de réseau dans un groupe de ressources qui contient un serveur de boîtes aux lettres en cluster. Toutefois, cette restriction n'existe pas dans Exchange 2007 SP1. Une fois le serveur de boîte aux lettres en cluster mis à niveau vers Exchange 2007 SP1, plusieurs ressources de nom de réseau peuvent exister dans le groupe de ressources qui contient le serveur de boîte aux lettres en cluster.

Configuration réseau pour l'installation de la CCR sous Windows Server 2008

La configuration réseau pour l'installation de la CCR sous Windows Server 2008 diffère légèrement de celle pour l'installation de la CCR sous Windows Server 2003. Comme pour Windows Server 2003, si vous installez la CCR sous Windows Server 2008, vous devez avoir un nombre suffisant d'adresses IP disponibles pour les deux nœuds et le serveur de boîtes aux lettres en cluster (CMS). En revanche, certaines options supplémentaires disponibles sous Windows Server 2008 ne le sont pas dans Windows Server 2003 :

  • Les nœuds de cluster peuvent résider dans différents sous-réseaux. Dans Windows Server 2003, l'interface des réseaux dans chaque nœud doit se trouver dans le même sous-réseau que le réseau correspondant dans l'autre nœud. Cette exigence n'existe pas dans Windows Server 2008. Aussi, les nœuds figurant dans un cluster de basculement peuvent communiquer via les routeurs réseau. Par ailleurs, la technologie LAN virtuelle (VLAN) n'a pas besoin d'être utilisée pour relier les nœuds.

  • Lorsque plusieurs sous-réseaux sont utilisés dans un environnement de CCR, il se peut que la réplication DNS affecte la capacité de reconnexion d'un client à un serveur CMS après le basculement ou le transfert du CMS entre les nœuds. Les clients et d'autres serveurs qui communiquent avec un serveur de boîtes aux lettres en cluster dont l'adresse IP a été modifiée ne peuvent pas rétablir de communications avec le serveur de boîtes aux lettres en cluster tant que le DNS n'a pas été mis à jour avec la nouvelle adresse IP et tant que tout cache DNS local n'a pas été mis à jour. Pour minimiser le temps nécessaire pour que les modifications de DNS soient connues des clients et d'autres serveurs, il est recommandé de définir une valeur de DNS TTL (Time to Live) de cinq minutes pour la ressource de nom de réseau du serveur de boîtes aux lettres en cluster. Dans la plupart des environnements, il est recommandé de définir la valeur de DNS TTL uniquement sur la ressource de nom de réseau du serveur de boîtes aux lettres en cluster. Toutefois, dans des environnements comprenant des outils de gestion non-Exchange qui se connectent au cluster par son nom à des fins de gestion, il est recommandé de définir une valeur TTL inférieure pour la ressource de nom de réseau du cluster. Pour obtenir la procédure détaillée de configuration des valeurs de DNS TTL pour les ressources de nom de réseau à utiliser dans un déploiement de serveur de boîtes aux lettres en cluster de sous réseau multiple ou de cluster de secours, consultez la rubrique Procédure de configuration des valeurs DNS TTL pour les ressources de nom de réseau.

  • Dans la fonctionnalité de cluster de basculement Windows Server 2008, il est possible que les ressources d’adresses IP obtiennent leur adressage des serveurs DHCP (Dynamic Host Configuration Protocol), ainsi que des entrées statiques. Si les noeuds de cluster eux-mêmes sont configurés pour obtenir leur adresse IP d'un serveur DHCP, le comportement par défaut sera d'obtenir une adresse IP automatiquement pour toutes les ressources d’adresses IP. Si le nœud de cluster possède des adresses IP attribuées de façon statique, les ressources d'adresses IP de cluster doivent également être configurées avec des adresses IP statiques. L'attribution de l'adresse IP d'une ressource d'adresse IP de cluster suit donc la configuration du nœud physique et de chaque interface spécifique sur le nœud. Il n'est pas recommandé d'utiliser le protocole DHCP pour les serveurs de boîtes aux lettres en cluster. Tenez compte des considérations suivantes avant d'utiliser le protocole DHCP pour un serveur CMS :

    • Le service de cluster ne met pas en ligne une ressource d'adresse IP DHCP si l'adresse IP change.

    • Les serveurs DHCP doivent être configurés pour octroyer un bail illimité pour toutes les adresses attribuées via le protocole DHCP utilisées par les serveurs de boîtes aux lettres en cluster.

  • Windows Server 2008 et son service de cluster prennent également en charge Internet Protocol version 6 (IPv6). Cela inclut la capacité de prendre en charge les ressources d'adresses IPv4 ou IPv6 soit individuellement soit combinées dans un cluster. En outre, les clusters de basculement prennent également en charge le protocole ISATAP (Automatic Tunneling Addressing Protocol) intra-site, mais ne prennent en charge que les adresses IPv6 autorisant un enregistrement dynamique dans DNS (enregistrements d’hôtes AAAA et zone de recherche inversée IP6.ARPA). L'utilisation d'adresses IPv6 et de plages d'adresses IP n'est prise en charge que si Exchange 2007 SP1 est déployé sur un ordinateur exécutant Windows Server 2008, si les protocoles IPv6 et IPv4 sont activés sur cet ordinateur et si le réseau prend en charge les deux versions d'adresse IP. En cas de déploiement d'Exchange 2007 SP1 dans cette configuration, tous les rôles serveur peuvent échanger des données avec des périphériques, des serveurs et des clients utilisant des adresses IPv6. Une installation par défaut de Windows Server 2008 prend en charge les protocoles IPv4 et IPv6. Si Exchange 2007 SP1 est installé sur Windows Server 2003, les adresses IPv6 ne sont pas prises en charge. Pour plus d'informations sur la prise en charge par Exchange 2007 SP1 des adresses IPv6, consultez la rubrique Prise en charge du protocole IPv6 dans Exchange 2007 SP1 et SP2.

Configuration réseau pour l'installation de la CCR sous Windows Server 2003

Si vous installez la CCR sous Windows Server 2003, vous devez détenir un nombre suffisant d'adresses IP statiques disponibles lorsque vous créez des serveurs de boîtes aux lettres en cluster dans une configuration CCR à deux nœuds. Une adresse IP est requise pour le cluster et le serveur de boîtes aux lettres en cluster. Par ailleurs, des adresses IP sont requises pour les réseaux publics et privés sur chaque nœud.

  • Adresses privées   Chaque noeud requiert une adresse IP statique pour chaque carte réseau utilisée pour le réseau privé en cluster. Vous ne devez pas utiliser d'adresses IP statiques qui se trouvent sur le même sous-réseau ou réseau que l'un des réseaux publics. Il est recommandé d'utiliser 10.10.10.10 et 10.10.10.11 avec un masque de sous-réseau de 255.255.255.0 pour les adresses IP privées respectives des deux nœuds. Si votre réseau public utilise un réseau 10.x.x.x et un masque de sous-réseau 255.255.255.0, il est recommandé d'utiliser des adresses IP de réseau privé et un masque de sous-réseau alternatifs. Si vous configurez plusieurs réseaux privés, des adresses uniques et des sous-réseaux sont requis pour chaque carte réseau privé et chaque réseau.

  • Adresses publiques   Chaque noeud requiert une adresse IP statique pour chaque carte réseau utilisée pour le réseau public en cluster. Par ailleurs, des adresses IP statiques sont requises pour le cluster de serveurs et le serveur de boîtes aux lettres en cluster, de façon à ce que les clients et les administrateurs puissent y accéder. Vous ne devez pas utiliser d'adresses IP statiques qui se trouvent sur le même sous-réseau ou réseau que l'un des réseaux privés.

Le réseau privé pour tous les nœuds d'un cluster doit être sur le même sous-réseau mais vous pouvez utiliser des commutateurs VLAN sur les interconnexions entre deux nœuds. Si vous utilisez un VLAN, la latence point à point, aller-retour, doit être inférieure à 0,5 seconde. En outre, la liaison entre deux noeuds doit apparaître en tant que connexion point à point unique dans la perspective d'exécution du système d'exploitation d'Windows Server 2003 sur les noeuds. Pour éviter les points de défaillance uniques, utilisez un matériel VLAN indépendant pour les différents chemins d'accès entre les noeuds. La même restriction de sous-réseau ne s'applique pas aux clusters de basculement fonctionnant sous Windows Server 2008.

Les réseaux publics pour tous les noeuds d'un cluster doivent se trouver sur le même sous-réseau et utiliser un sous-réseau différent de celui utilisé pour les réseaux privés. La même restriction de sous-réseau ne s'applique pas aux clusters de basculement fonctionnant sous Windows Server 2008.

L'ordre des connexions du réseau en cluster dans Windows doit être configuré afin que les réseaux publics figurent au début de la liste d'ordre des connexions. L'ordre de priorité du réseau dans le cluster doit être configuré avec les réseaux privés indiqués au début de l'ordre de priorité.

Si vous installez la CCR sous Windows Server 2003 dans une configuration avec plusieurs centres de données :

  • Tous les réseaux utilisés pour l'accès au client doivent fournir une bande passante adéquate et une latence suffisamment basse pour permettre aux clients d'accéder au serveur de boîtes aux lettres en clusters à partir de chacun des centres de données.

  • Tous les réseaux publics utilisés pour répliquer les journaux des transactions, doivent également offrir une bande passante adéquate et une latence suffisamment basse pour copier les fichiers journaux en temps voulu, de telle sorte que, chaque fois que cela est possible, il n'y ait pas de copie de sauvegarde des fichiers journaux.

  • les réseaux utilisés pour les pulsations de cluster doivent pouvoir expédier et recevoir un paquet de pulsations sans dépasser le nombre maximal de nouvelles tentatives configuré. Si vous installez la CCR pour Windows Server 2003 SP 2 ou Windows Server 2003 SP 1 et le correctif décrit dans l'article 921181 de la Base de connaissances sur la mise à jour qui ajoute une fonctionnalité de témoin de partage de fichiers et de pulsations de cluster configurable aux clusters de serveurs Windows Server 2003 Service Pack 1, les nouvelles tentatives de pulsation d'interface perdue et les nouvelles tentatives de pulsation de nœud perdu sont exposées comme des propriétés de configuration de cluster. Si vous installez CCR sur Windows Server 2008, cette mise à jour n'est pas nécessaire. Dans les deux cas, des pulsations sont toujours envoyées à intervalles de 1,2 seconde, mais vous pouvez configurer le cluster de façon à ce qu'un plus grand nombre d'échecs soient tolérés (résultant de paquets abandonnés, d'une latence excessive, d'un échec d'interface ou d'une défaillance de noeud) avant le lancement d'une quelconque action de récupération. Les valeurs de propriété sont exprimées en unités de pulsations manquées et de temps non écoulé. Ainsi, il n'est pas possible de configurer le cluster pour qu'il soupçonne une défaillance d'interface après cinq secondes. Il est possible de le configurer pour soupçonner une défaillance d'interface après cinq échecs ; selon le moment où la défaillance se produit réellement dans la période de pulsation, cinq échecs correspondent approximativement à cinq à six secondes. Ces deux paramétrages sont sujets à une valeur minimale de 2 secondes et une valeur maximale de 20 secondes.

Optimisation du réseau Windows 2003 pour la CCR

Lorsque vous utilisez la CCR 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 les nœuds actif et passif. 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 CCR. Les deux nœuds doivent utiliser le protocole IPsec ou aucun d'entre eux ne doit 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é du canal réseau 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. Vous pouvez télécharger le calculateur à partir du blog de l'équipe Exchange ici. Le calculateur de stockage inclut également des instructions détaillées sur la saisie de valeurs de Registre sur vos serveurs.

Notes

UNRESOLVED_TOKEN_VAL(exBlog) 

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.

Ces fonctionnalités peuvent apporter des avantages en termes de performances du réseau dans certains environnement. Certains scénarios ne permettent toutefois 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.

Notes

UNRESOLVED_TOKEN_VAL(exBlog)

Il est recommandé de désactiver toutes les fonctionnalités dans les environnements de CCR 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.

Comportement d'Outlook après le basculement d'un serveur de boîtes aux lettres en cluster dans un cluster de basculement de sous-réseau multiple

En cas de déplacement ou de basculement d'un serveur de boîtes aux lettres en cluster déployé dans un cluster de basculement de sous-réseau multiple et géographiquement dispersé, le nom du serveur de boîtes aux lettres en cluster est conservé. Toutefois, l'adresse IP affectée à ce nom n'est pas conservée. La disponibilité de ce serveur pour des clients et d'autres serveurs dépend de la propagation de la nouvelle adresse IP sur le DNS. La propagation DNS peut prendre un certain temps. C'est pourquoi il est recommandé de configurer une valeur de durée de vie (TTL, Time to Live) pour l'enregistrement d'hôte DNS de serveur de boîtes aux lettres en cluster sur une valeur de 5 minutes (300 secondes). Pour obtenir la procédure détaillée de configuration de la valeur de DNS TTL pour le serveur de boîtes aux lettres en cluster, consultez la rubrique Procédure de configuration des valeurs DNS TTL pour les ressources de nom de réseau. Une fois la valeur de DNS TTL configurée pour le serveur de boîtes aux lettres en cluster, vous devez arrêter, puis démarrer celui-ci pour activer les modifications.

Bien que des clients Microsoft Office Outlook internes n'aient pas besoin de profils nouveaux ou reconfigurés pour se connecter à l'aide de la nouvelle adresse IP, ils doivent attendre que leur cache DNS local soit effacé de façon à ce que la résolution du nom du serveur de boîtes aux lettres en cluster soit déplacée de l'ancienne adresse IP vers la nouvelle. Une fois l'adresse IP propagée vers les serveurs DNS appropriés, il est possible d'effacer le cache DNS sur les clients Outlook en exécutant la commande suivante dans la ligne de commande sur le client :

ipconfig /flushdns

Les sections suivantes présentent le comportement d'Outlook dans différentes configurations.

CCR étendue sous Windows Server 2003 (un seul sous-réseau)

Dans cette configuration, la ressource de nom de réseau n'est dépendante que d'une seule ressource de nom de réseau et d'une seule ressource d'adresse IP. Dans DNS, le nom de réseau est associé à l'adresse IP. Toutes les ressources, dont la ressource d'adresse IP, peuvent se déplacer entre les deux noeuds du cluster. Du point de vue d'Outlook, aucune modification d'adresse IP n'a lieu étant donné que la seule modification de réseau au cours du basculement correspond à l'association de l'adresse IP à l'adresse MAC de l'ordinateur, qui est transparente aux clients.

CCR étendue sous Windows Server 2008 (deux sous-réseaux utilisant IPv4)

Dans cette configuration, le nom de réseau est dépendant d'une seule ressource de nom de réseau et de deux adresses IP, en tant que « OU » logique . Dans DNS, le nom de réseau est associé à l'adresse IP en ligne actuelle. Au cours du basculement, alors que la ressource de nom de réseau est mise en ligne, le service de cluster met à jour l'entrée DNS du nom de réseau avec la deuxième adresse IP, qui correspond à l'autre sous-réseau. La mise à jour de l'enregistrement doit se propager via DNS. Du point de vue d'Outlook, Outlook ne requiert pas de nouveau profil ou d'un profil reconfiguré, mais doit attendre le vidage du cache DNS local pour que le nom de réseau soit en mesure de résoudre l'autre adresse IP. Vous pouvez exécuter cette opération manuellement sur le client en exécutant la commande suivante :

IPConfig /flushdns

CCR locale avec SCR sur un site distant (un ou deux sous-réseaux)

Dans cette configuration, le nom de réseau n'est dépendant que d'une seule ressource de nom de réseau et d'une seule ressource d'adresse IP. Toutes les ressources, dont l'adresse IP, peuvent se déplacer entre les deux noeuds du cluster. Lors du basculement d'un site sur lequel la cible de SCR est activée en exécutant Setup.com /recoverCMS, le serveur de boîtes aux lettres en cluster est déplacé vers un autre site/cluster. Au cours de l'exécution de cette commande, vous spécifiez l'adresse IP devant être associée au nom de réseau sur le site distant. Le programme d'installation crée les ressources de nom de réseau et d'adresse IP et le service de cluster met à jour DNS avec la nouvelle adresse IP. La mise à jour de DNS doit se propager via DNS. Du point de vue d'Outlook, Outlook ne requiert pas de nouveau profil ou d'un profil reconfiguré, mais doit attendre le vidage du cache DNS local pour que le nom de réseau soit en mesure de résoudre l'autre adresse IP. Vous pouvez exécuter cette opération manuellement sur le client en exécutant la commande suivante :

IPConfig /flushdns

Configuration de stockage pour la réplication continue en cluster

CCR est conçu pour éliminer le besoin de stockage partagé dans un cluster Windows. Le stockage partagé était une exigence des versions précédentes d'Exchange. Les seules exigences de stockage pour la CCR sont d'offrir une capacité et des performances suffisantes de stockage pris en charge par Windows.

La CCR n'impose aucune prise en compte des E/S supplémentaires sur le stockage utilisé par les groupes de stockage et les bases de données. Lorsque vous concevez votre solution de stockage CCR, nous vous recommandons d'appliquer les meilleures pratiques suivantes :

  • La localisation des groupes de stockage et de bases de données doit être identique dans tous les noeuds de cluster.

  • Stockez les fichiers de base de données et les fichiers journaux de transactions sur des numéros d'unité logique (LUN) différents.

  • Utilisez les points de montage de volume de système de fichiers NTFS pour apprêter les volumes du système d'exploitation.

  • Utilisez des noms identifiables qui peuvent être directement et objectivement liés au groupe de stockage ou à la base de données hébergé. Si plusieurs volumes sont utilisés pour les journaux et les bases de données, les chemins d'accès doivent identifier le type de données. Cette approche peut permettre de limiter les erreurs humaines lorsque le nombre de bases de données et de groupes de stockage augmente. En cas d'exécution de l'installation par défaut, le groupe de stockage et les bases de données sont créés sous l'emplacement d'installation d'Exchange 2007.

    Notes

    Exchange 2007 ne prend pas en charge le placement des fichiers du journal des transactions ou des fichiers de base de données à la racine du volume.

Un environnement CCR requiert un stockage offrant des performances et une capacité adéquates. Un stockage équivalent pour les performances et la capacité du système doit être configuré sur les deux noeuds en utilisant le même emplacement (lettre de lecteur et chemin d'accès) pour chaque groupe de stockage et base de données.

Taille de base de données et réplication continue en cluster

La première ligne de défense suite à une défaillance de stockage catastrophique ou un endommagement physique de la base de données avec CCR consiste à revenir à la copie passive des données et à ne pas restaurer à partir de la sauvegarde. Cela réduit sensiblement l'importance d'avoir des objectifs de temps de récupération (RTO) courts basés sur une restauration à partir d'une archive ou d'une bande. Au lieu d'opérer la restauration à partir d'une bande, vous pouvez activer la copie passive d'une base de données et les données sont disponibles pour les clients en l'espace de quelques minutes au lieu de plusieurs heures. C'est ainsi que la CCR peut être considérée comme un mécanisme de récupération rapide, ce qui la met dans la même catégorie que les instantanés matériels et les duplications créés à l'aide du Service VSS dans Exchange Server 2003.

Il n'est pas rare qu'un administrateur doive effectuer des opérations de base de données en mode hors connexion, telles que des réparations suite à des problèmes de sauvegarde (par exemple, bande défectueuse ou échec de restauration). La CCR permet d'éviter ce scénario et réduit la probabilité de devoir réparer une base de données. Si le pourcentage de situations où une réparation s'impose a sensiblement diminué, ce type d'opération reste occasionnellement nécessaire. Tenez compte de la tolérance aux temps morts dans le pire des cas lorsque vous fixez la taille de base de données.

La CCR permet de ménager des fenêtres de maintenance en ligne plus longues. Comme la CCR permet d'effectuer une sauvegarde à partir de la copie passive d'un groupe de stockage, vous devez allonger votre fenêtre de maintenance en ligne sur le noeud de cluster actif. Dans de nombreux cas, vous devez doubler la fenêtre de maintenance en ligne, ce qui vous permet de disposer de boîtes aux lettres et de bases de données de plus grande taille.

Une autre fonctionnalité d'Exchange 2007, nommée Lost Log Resiliency (LLR), réduit sensiblement l'occurrence d'incohérences de bases de données dues à des pertes de journal. En règle générale, la raison la plus fréquente pour laquelle un administrateur répare une base de données consiste à la rétablir dans un état cohérent suite à la perte ou l'endommagement de journaux requis, empêchant ainsi le montage de la base de données. La LLR offre une tolérance à un grand nombre de ces scénarios de perte et endommagement de journal, ce qui permet de monter une base de données sans devoir exécuter de réparation. Pour plus d'informations sur la LLR, consultez la rubrique Capacité de résilience à la perte de journaux et activité du journal des transactions dans Exchange 2007.

À ce stade, vous pensez peut-être que la réplication continue permet d'augmenter la taille des bases de données à votre guise sans aucun risque. Ce n'est cependant pas le cas. La maintenance en ligne effectuée dans un délai raisonnable par base de données reste un facteur limitant la taille de base de données. Toutefois, avec la CCR, la possibilité de devoir réamorcer des bases de données est également un facteur limitant. La CCR assure la redondance des bases de données. Ainsi, en cas de perte ou d'endommagement de la copie active d'une base de données, vous pouvez la récupérer rapidement en activant la copie passive. La CCR effectue une activation automatique via le processus de basculement.

Une fois le basculement effectué, il ne reste qu'une seule copie de la base de données ; la nouvelle copie active. Comme la copie passive n'existe plus, il se peut que la tolérance de base de données soit compromise. Toutefois, vous disposez encore de la sauvegarde. Pour réactiver la résilience, il convient de supprimer la base de données perdue ou endommagée et de créer et amorcer une copie passive de celle-ci à partir de la copie active. Cette opération peut prendre du temps, selon la taille de la base de données. Le pire scénario consiste en la perte ou l'endommagement de toutes les copies actives, alors que toutes les copies passives doivent être réamorcées. Ce scénario justifie la recommandation d'utiliser Gigabit Ethernet pour les environnements CCR.

Dans un environnement de CCR, vous devez vous attendre à voir les taux suivants sur Gigabit Ethernet en l'absence d'étranglement de disque ou de processeur :

  • Réamorçage de base de données unique : environ 25 Mo par seconde

  • Réamorçage de plusieurs bases de données (en parallèle) : environ 100 Mo/sec (limités par la bande passante du réseau).

Il est possible de disposer d'une taille de base de données maximale plus élevée lorsque la réplication continue est utilisée. Voici les tailles de base de données maximales recommandées pour Exchange 2007 :

  • Bases de données hébergées sur un serveur de boîtes aux lettres sans réplication continue : 100 gigaoctets (Go)

  • Bases de données hébergées sur un serveur de boîtes aux lettres avec réplication continue et Gigabit Ethernet : 200 Go

    Notes

    Des bases de données de grande taille peuvent également nécessiter une technologie de stockage plus récente en cas d'élargissement de la bande passante afin de s'adapter aux scénarios de réparation.

    Important

    La taille maximale réelle de vos bases de données dépend du contrat SLA conclu par votre organisation. Le calcul de la taille maximale de base de données pouvant être sauvegardée et restaurée au cours d'une période donnée aux termes du contrat SLA de votre organisation équivaut à déterminer la taille maximale de vos bases de données.

Configuration requise d'Active Directory pour la réplication continue en cluster

La CCR a les mêmes exigences d'infrastructure Active Directory alors qu'un serveur autonome a des exigences supplémentaires. Dans une solution de centres de données multiples, chacun des centres de données doit prendre en charge l'infrastructure Active Directory adéquate car, à tout moment, un des centres de données pourrait héberger le serveur de boîtes aux lettres en clusters. Cette capacité doit être présente même si les autres centres de données sont indisponibles. En outre, tous les noeuds du cluster doivent être dans le même domaine et le compte de service de cluster doit disposer des autorisations appropriées.

Notes

Les serveurs de boîte aux lettres dans un cluster dispersé sur le plan géographique requièrent l’extension d’un site unique Active Directory entre les centres de données parce que tous les noeuds dans le cluster doivent être membres du même site. Cependant, il n’y a aucune exigence que d’autres serveurs dans les deux centres de données soient sur le même sous-réseau ou dans le même site Active Directory.

Configuration requise du compte de service pour la réplication continue en cluster

Si vous installez CCR sur Windows Server 2008, le compte de service de cluster s'exécute sous le compte LocalSystem (SYSTEM).

Si vous installez CCR sur Windows Server 2003, vous devez utiliser un compte de domaine pour le compte de service de cluster. Tous les noeuds du cluster doivent être membres du même domaine et utiliser le même compte de service de cluster. Le compte de service de cluster doit également être membre du groupe Administrateurs local sur chaque noeud capable d'héberger un serveur de boîtes aux lettres en cluster.

Le compte de service de cluster est responsable de la création et de la gestion du compte d'ordinateur identifié par et associé avec la ressource de nom de réseau du cluster de basculement lorsque cette ressource est mise en ligne. Pour s'assurer que le compte de service de cluster dispose des autorisations appropriées, consultez l'article 307532 de la Base de connaissances Microsoft sur le dépannage du compte de service de cluster lorsqu'il modifie les objets d'ordinateur. Des informations supplémentaires sont disponibles dans l'article 251335 de la Base de connaissances, Les utilisateurs d'un domaine ne peuvent pas joindre une station de travail ou un serveur à un domaine.

Réplication continue en cluster et bases de données de dossiers publics

La CCR 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 CCR.

Les configurations recommandées pour l'utilisation de bases de données de dossiers publics et de la CCR 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 en cluster dans un environnement de CCR, celui-ci peut héberger une base de données de dossiers publics. 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 du dossier public est désactivée. Dans ce scénario, la redondance de base de données de dossiers publics est rendue possible grâce à la CCR, qui conserve deux copies de votre base de données de dossiers publics.

  • Si vous disposez de plusieurs serveurs de boîtes aux lettres, vous pouvez héberger une base de données de dossiers publics dans un environnement de CCR à condition que l'organisation Exchange ne comporte qu'une base de données de dossiers publics. Dans ce scénario, la redondance de base de données de dossiers publics est également rendue possible grâce à la CCR. 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.

  • Si vous procédez à la migration de données de dossiers publics vers un environnement de CCR, 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 un serveur de boîtes aux lettres en cluster dans un environnement de CCR. Une fois que avez créé la base de données de dossiers publics dans un environnement de CCR, les bases de données de dossiers publics supplémentaires doivent être présentes jusqu'à la réplication complète de vos données de dossiers publics dans l'environnement de CCR. Une fois la réplication effectuée, toutes les bases de données de dossiers publics en dehors de l'environnement de CCR doivent être déplacé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 depuis un environnement de CCR, 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 en cluster dans un environnement de CCR vers un serveur de boîtes aux lettres autonome ou un serveur de boîtes aux lettres dans un SCC. Une fois que avez créé la base de données de dossiers publics supplémentaire en dehors de l'environnement de CCR, les bases de données de dossiers publics dans l'environnement de CCR doivent être présentes jusqu'à la réplication complète de vos données de dossiers publics dans les bases de données de dossiers publics supplémentaires. Lorsque la réplication est terminée avec succès, toutes les bases de données de dossiers publics dans les environnements de CCR 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 réplication continue.

Lors des périodes au cours desquelles 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 environnement de CCR (tels que les scénarios de migration décrits précédemment), tenez compte des différences de comportement des interruptions programmées (sans perte) et non programmées (avec perte) :

  • Dans le cas où une interruption programmée sans perte réussit, la base de données de dossiers publics sera mise en ligne et la réplication du dossier public devrait continuer comme attendu.

  • Dans le cas où une interruption non programmée survient, la base de données de dossiers publics n'est pas mise en ligne jusqu'à ce que le serveur original soit disponible ainsi que tous les journaux pour le groupe de stockage hébergeant la base de données de dossiers publics. Si aucune donnée n'est perdue suite à l'interruption, la CCR ne permet pas la mise en ligne de la base de données de dossiers publics lorsque la réplication de dossiers publics est active. Dans ce cas, le nœud original doit être mis 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 le serveur de boîtes aux lettres en cluster dans l'environnement de CCR et son contenu doit être récupéré à l'aide de la réplication de dossiers publics à partir de bases de données de dossiers publics en dehors de l'environnement de CCR.

Sauvegarde et restauration, et réplication continue en cluster

Les sauvegardes Exchange sont prises en charge pour les bases de données et les groupes de stockage de production et de copie à l'aide de la technologie VSS. Les sauvegardes en continu ne sont prises en charge que depuis le noeud actif.

Notes

Une tâche courante durant les sauvegardes Exchange est la troncature des fichiers journaux de transactions une fois la sauvegarde terminée. La fonction de réplication dans une CCR garantit que les journaux non répliqués ne sont pas supprimés. Ce comportement implique que l'exécution de sauvegardes dans un mode qui supprime les journaux risque de ne pas réellement libérer d'espace si la réplication intervient avec un retard suffisant sur la copie du journal.

Les restaurations Exchange de la copie active peuvent être effectuées soit à l'aide d'une transmission en continu, soit à l'aide de solutions de sauvegarde VSS. Les restaurations Exchange ne sont pas prises en charge pour la copie passive.

Notes

Avant d'effectuer une restauration, vous devez supprimer tous les fichiers de groupe de stockage et de base de données de la copie passive du groupe de stockage.

Après la restauration d'une base de données à partir d'une sauvegarde dans un groupe de stockage dans un environnement de CCR, 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 de Microsoft Exchange disposera d'informations de génération de journaux obsolètes et arrêtera la réplication des fichiers journaux.

Total de contrôle de la maintenance en ligne des bases de données et réinitialisation de la page Nouvelle base de données dans Exchange 2007 SP1

Le total de contrôle est le processus de vérification de l'intégrité de la base de données. Le nettoyage de page est le processus de réinitialisation des bases de données à la fin d'une sauvegarde en continu. Exchange 2007 RTM calcule les totaux d'une base de données entière lors de la sauvegarde complète en ligne de transmission en continu d'une base de données. Comme indiqué précédemment, dans un environnement de réplication continue, les sauvegardes continues ne peuvent être effectuées que par rapport à la copie active d'une base de données. Vous ne pouvez pas effectuer de sauvegarde en continu d'une copie passive de base de données. VSS peut être utilisé pour effectuer des captures instantanées complètes ou des clones d'une copie passive ; les captures instantanées complètes et les clones peuvent également être calculés. Mais généralement, dans un environnement de réplication continue, seule une des copies de base de données (l'active ou la passive) peut être calculée sans intervention de l'administrateur et avec un délai d'inactivité. Voici les raisons :

  • Il est contraignant d'effectuer des sauvegardes continues de la copie active d'une base de données et d'effectuer des sauvegardes VSS de la copie passive d'une même base de données.

  • Bien que VSS puisse être utilisé à la fois pour les copies de base de données active et passive, une telle opération est contraire à la recommandation indiquant de décharger les opérations de sauvegarde de la copie active vers la copie passive.

  • La résilience peut être temporairement compromise puisque l'exécution manuelle de contrôles d'intégrité à l'aide d'Exchange Server Database Utilities (Eseutil) nécessite la suspension de la réplication continue.

Pour activer le nettoyage de page et le total de contrôle de base de données sur toutes les copies de base de données sans problèmes ou sans avoir à résoudre les problèmes décrits auparavant, Exchange 2007 SP1 présente deux nouvelles fonctionnalités : Total de contrôle de la maintenance en ligne des bases de données et Réinitialisation de la page de maintenance en ligne des bases de données. Ces fonctionnalités permettent à un administrateur d'activer le nettoyage de page en arrière-plan et le total de contrôle en arrière-plan d'une base de données. Vous pouvez activer chacune de ces fonctionnalités séparément ou simultanément en configurant manuellement les valeurs de Registre du serveur de boîte aux lettres contenant les bases de données à analyser puis en redémarrant le service de banque d'informations de Microsoft Exchange. Les valeurs de Registre sont configurées au niveau de la banque d'informations Microsoft Exchange. Ensuite, après l'activation, toutes les bases de données du serveur de boîte aux lettres effectuent l'activité d'arrière-plan configurée. Les entrées de Registre disponibles sont décrites ultérieurement dans cette rubrique.

CautionAttention :
UNRESOLVED_TOKEN_VAL(exRegistry)

Activer le total de contrôle de la maintenance en ligne des bases de données

Emplacement : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Nom : Total de contrôle de maintenance en ligne

Tapez : REG_DWORD

Valeur : 0x00000001

Activer la réinitialisation de la page de maintenance en ligne des bases de données

Emplacement : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Nom : Réinitialiser les pages de base de données pendant le total de contrôle

Tapez : REG_DWORD

Valeur : 0x00000001

Limitation du total de contrôle de la maintenance en ligne des bases de données

Emplacement : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Nom : Limiter le total de contrôle

Tapez : REG_DWORD

Valeur : 0x00000000 (millisecondes)