Nouvelles fonctionnalités de haute disponibilité dans Exchange 2007 SP1

S’applique à : Exchange Server 2007 SP1

Dernière rubrique modifiée : 2009-03-18

Microsoft Exchange Server 2007 Service Pack 1 SP1 introduit plusieurs nouvelles fonctionnalités pour offrir une haute disponibilité et apporte des améliorations aux fonctionnalités haute disponibilité existantes. Les fonctionnalités inédites et améliorées élargissent les scénarios dans lesquels vous pouvez bénéficier d'une disponibilité des données et services pour vos rôles serveur Exchange 2007. Les nouveaux scénarios permettent aux organisations de distinguer les scénarios de haute disponibilité des scénarios de résilience de site et de déployer des configurations personnalisées pour leurs besoins spécifiques dans chaque zone distincte.

Exchange 2007 SP1 ajoute les nouvelles fonctionnalités et améliorations suivantes aux fonctionnalités de haute disponibilité existantes :

• Réplication continue de secours (Standby continuous replication - SCR)

• Prise en charge des fonctionnalité suivantes dans Windows Server 2008 :

  • Clusters de basculement constitué de plusieurs sous-réseaux

  • Protocole DHCP (Dynamic Host Configuration Protocol) et IPv4 (Internet Protocol version 4)

  • IPv6

  • Configuration du réseau de clusters de basculement Exchange

  • nouveaux modèles de quorum (témoin de partage de disque et de fichier) ;

• réplication continue (envoi et amorçage de journal) sur un réseau en cluster redondant dans un environnement de réplication continue en cluster (CCR) ;

• améliorations de la création de rapports et de la surveillance ;

• améliorations liées aux performances ;

• améliorations du conteneur de dépôt de transport ;

• améliorations apportées à la console de gestion Exchange.

Chacune de ces fonctionnalités est décrite ultérieurement dans cette rubrique, qui contient également des liens vers la documentation relative à la planification, au déploiement et à la gestion de ces fonctionnalités. Le tableau suivant résume la prise en charge Exchange 2007 des fonctionnalités des clusters de basculement sous Windows Server 2003 et Windows Server 2008.

Fonctionnalités des clusters de basculement pris en charge par Exchange 2007 SP1

Réplication continue de secours

SCR est une nouvelle fonctionnalité offerte dans Exchange 2007 SP1. La SCR étend les fonctionnalités de réplication continue existantes d'Exchange 2007 RTM 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 réplication continue locale (LCR) et la CCR afin d'offrir des options et configurations de déploiement supplémentaires. Bien que la SCR ressemble à la LCR et à la CCR, elle possède des caractéristiques qui lui sont propres :

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

• SCR permet à l’administrateur de spécifier une durée de décalage pour la réplication. Cette fonctionnalité est précieuse dans plusieurs scénarios. Par exemple, en cas de basculement figé du noeud A au noeud B, si les fichiers journaux perdus ont été relus sur le noeud M distant, ce dernier doit subir un nouveau réamorçage. Toutefois, si les fichiers journaux sont copiés sans être relus, ils peuvent être supprimés et de nouveaux fichiers journaux peuvent ensuite être copiés avant d’être relus. Dans ce cas, aucun réamorçage de la copie du noeud M n’est nécessaire.

• Contrairement à CCR et LCR, il est impossible de sauvegarder une copie SCR. Lorsque SCR est utilisé, les en-têtes de base de données des copies SCR sont mis à jour et les fichiers journaux sont tronqués lorsque des sauvegardes sont prises en charge sur le groupe de stockage source.

SCR permet d’utiliser la réplication continue pour répliquer les données du serveur de boîtes aux lettres depuis un serveur de boîtes aux lettres autonome ou depuis un serveur de boîtes aux lettres en cluster dans un environnement SCC ou CCR.

Le processus d'activation des copies des données du serveur de boîtes aux lettres créées et gérées par SCR est manuel. Il est conçu pour être utilisé lorsqu'une défaillance importante se produit (et non pas pour de simples interruptions de serveurs qui sont récupérables par 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.

Prise en charge pour Windows Server 2008

Windows Server 2008 offre de nouvelles fonctionnalités haute disponibilité prises en charge par Exchange 2007 SP1. Dans Windows Server 2008, les améliorations apportées aux clusters de basculement (également appelés clusters de serveur dans Windows Server 2003 et des versions antérieures) ont pour but de simplifier les clusters, de les sécuriser et d’améliorer leur stabilité. En outre, l’installation et la gestion des clusters ont été facilitées et les composants de sécurité, de mise en réseau et de stockage des clusters ont été améliorés. Pour obtenir la liste complète des améliorations apportées aux clusters de basculement, consultez la rubrique sur les clusters de basculement de Windows Server 2008.

En plus de prendre en charge Windows Server 2008 comme plateforme de système d’exploitation, Exchange 2007 SP1 prend également en charge les fonctionnalités suivantes des clusters de basculement Windows Server 2008. Une prise en charge de ces fonctionnalités a également été intégrée dans le programme d’installation Exchange 2007 pour la version de ligne de commande (Setup.com) et la version de l’interface utilisateur graphique (GUI) (Setup.exe, également appelée Assistant Installation Exchange Server 2007).

Prise en charge de plusieurs clusters de basculement de sous-réseau

La fonctionnalité de cluster avec basculement de Windows Server 2008 introduit de nouvelles capacités réseau qui constituent une progression majeure par rapport à la manière dont les choses ont été faites dans les clusters hérités. Par exemple, les clusters de basculement Windows Server 2008 introduisent la prise en charge de plusieurs sous-réseaux. En cas d'exécution dans un cluster avec basculement Windows Server 2008, Exchange 2007 SP1 inclut une prise en charge de clusters dispersés géographiquement pour le basculement entre deux sous-réseaux. Cette prise en charge inclut les deux SCC, ainsi que des serveurs de boîtes aux lettres dans un environnement de réplication continue en cluster (CCR).

En commençant par un cluster avec basculement Windows Server 2008, des noeuds de cluster individuels peuvent à présent être situés sur des réseaux routés séparés. Cela requiert que les ressources qui dépendent de ressources d'adresse IP (par exemple, ressources de nom de réseau), implémentent une logique OR car il est improbable que chaque noeud de cluster ait une connexion locale directe avec chaque réseau connu du cluster. Cela aide les ressources d'adresse IP et de nom de réseau à entrer en mode connexion lorsque des services ou des applications basculent vers des noeuds distants.

Important :
Tous les noeuds de cluster des environnements SCC ou CCR doivent être dans le même site Active Directory. Bien que les clusters de basculement Windows Server 2008 introduisent la prise en charge des noeuds de cluster membres de sites Active Directory différents, cette configuration n’est pas prise en charge par Exchange 2007.

Lors de l’utilisation de clusters de basculement disposant de plusieurs sous-réseaux, les adresses IP associées à la ressource de nom de réseau sont enregistrées dynamiquement dans le DNS (Domain Name System) (s’il est configuré pour des mises à jour dynamiques) lors de leur mise en ligne. Par conséquent, seules les ressources d’adresses IP en ligne sont renvoyées aux clients. Comme des noeuds de cluster peuvent être placés sur différents réseaux routés et comme les mécanismes de communication ont été modifiés pour utiliser des protocoles de session fiables implémentés sur UDP (User Datagram Protocol) (unicast), les configurations réseau requises pour des clusters dispersés géographiquement Windows Server 2003 ne sont plus applicables dans Windows Server 2008. Par conséquent, des organisations peuvent déployer un environnement SCC ou CCR entre deux centres de données physiques sans devoir utiliser une technologie LAN (VLAN) pour étendre les sous-réseaux.

En cas de déplacement ou de basculement d'un serveur de boîtes aux lettres en cluster déployé dans un cluster avec basculement de sous-réseau multiple et géographiquement dispersé, le nom du serveur de boîtes aux lettres en cluster est conservé mais l'adresse IP affectée à ce nom ne l'est pas. 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 10 minutes.

Bien que des clients Microsoft 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 adresse IP. 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 à l'aide de la commande suivante dans la ligne de commande sur le client.

ipconfig /flushdns

Prise en charge de DHCP-IPv4

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, 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 noeud de cluster possède des adresses IP attribuées statiquement, les ressources d’adresses IP de cluster devront également être configurées avec des adresses IP statiques. L’attribution IP d’une ressource d’adresses IP de cluster suit donc la configuration du noeud physique et de chaque interface spécifique sur le noeud.

prise en charge du protocole IPv6 ;

Windows Server 2008 et le service de clusters prend en charge 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). Actuellement, il existe trois types d’adresses IPv6 : global, site local et de liaison locale. Les enregistrements DNS dynamiques ne se produisent pas pour les adresses de liaison locale et par conséquent, les adresses locales ne peuvent pas être utilisées dans un cluster.

Configuration du réseau de clusters de basculement Exchange

Lors de la configuration d’un SCC ou CCR pour Exchange 2007 SP1, tenez compte des exigences suivantes :

• Les protocoles IPv6 et DHCP IPv4 ne sont pris en charge que sur Windows Server 2008. Aucun de ces protocoles ne peut être utilisé lorsque Exchange 2007 est en cours d’exécution sur Windows Server 2003.

• Le protocole IPv6 DHCP n’est pas pris en charge par Windows Server 2008 ou le service de cluster. C’est pourquoi, il n’est pas non plus pris en charge par Exchange 2007. Seules les adresses IPv6 attribuées dynamiquement par le système sont prises en charge.

• Les adresses IPv6 statiques sont prises en charge par Windows Server 2008 et le service de cluster. Toutefois, l'utilisation d'adresses IPv6 statiques est contraire aux meilleures pratiques. C'est pourquoi, Exchange 2007 ne prend pas en charge la configuration des adresses IPv6 statiques en cours d'installation.

• Le tunneling IPv6 sur IPv4 est pris en charge par la fonctionnalité de cluster Windows Server 2008, mais le programme d’installation d’Exchange n’active pas la création de ce type de ressources d’adresses IP.

Le programme d’installation a été modifié dans Exchange 2007 SP1 pour prendre en charge les modifications décrites ci-avant. Lorsque vous utilisez l’Assistant Installation Exchange Server 2007, notez que des pages et des champs supplémentaires sont disponibles pour la configuration des adresses IP de cluster et des ressources de nom de réseau. En outre, les options /NewCMS et /RecoverCMS de Setup.com ont été mises à jour pour prendre en charge plusieurs nouveaux paramètres facultatifs, qui sont documentés dans le tableau suivant.

Paramètres facultatifs pour /NewCMS et /RecoverCMS ajoutés à Exchange 2007 SP1

Le paramètre CMSIPAddress, obligatoire pour /NewCMS et /RecoverCMS dans la version de publication (RTM) de Microsoft Exchange Server 2007, est encore utilisé pour spécifier une adresse IPv4 statique pour le serveur de boîtes aux lettres en cluster. Toutefois, dans Exchange 2007 SP1, le paramètre CMSIPAddress est désormais facultatif car la spécification d’un des quatre paramètres disponibles est suffisante pour le programme d’installation.

Les paramètres du tableau ci-avant ne peuvent être pris en charge que sous Windows Server 2008.

Nouvelles modèles de quorum dans Windows Server 2008

Lorsque des problèmes de réseau surviennent, ils peuvent interférer avec les communications entre les noeuds de cluster. Il se peut qu’un petit nombre de noeuds puisse communiquer entre eux via la partie en fonctionnement d’un réseau mais ne puisse pas communiquer avec un jeu de noeuds différent dans une autre partie du réseau. Cette situation peut provoquer de sérieux problèmes. Dans cette situation, au moins un des jeux de noeuds doit arrêter de s’exécuter en tant que cluster, même si les jeux de noeuds n’ont pas d’informations définitives sur l’état des autres noeuds.

Pour éviter les problèmes provoqués par une séparation dans le cluster, le logiciel de cluster requiert que tous les jeux de noeuds exécutés en tant que cluster utilisent un algorithme de vote pour déterminer si, à une heure spécifique, le jeu a un quorum. Un cluster spécifique étant doté d’un jeu de noeuds et d’une configuration de quorum spécifiques, le cluster sait combien de votes constituent une majorité, c’est-à-dire un quorum. Si le nombre de votes est inférieur à la majorité, le cluster arrête de fonctionner. Les noeuds écouteront la présence d’autres noeuds apparaissant à nouveau sur le réseau mais ne commenceront pas à fonctionner en tant que cluster tant que le quorum n’existera pas à nouveau.

La configuration du quorum dans un cluster de basculement détermine le point auquel de trop nombreuses défaillances stopperont l’exécution du cluster. Les défaillances concernées dans ce contexte sont des défaillances de noeuds ou, dans certains cas, un disque témoin ou un partage de fichiers témoin (qui contient une copie de la configuration de cluster). Windows Server 2008 permet de choisir parmi quatre configurations de quorum possibles :

• Noeud majoritaire   Ce modèle est recommandé pour les clusters disposant d’un nombre impair de noeuds. Il peut prendre en charge les défaillances de la moitié des noeuds moins 1. Par exemple, un cluster à sept noeuds peut prendre en charge 3 défaillances de noeuds.

• Noeud et disque majoritaire   Ce modèle est recommandé pour les clusters disposant d’un nombre pair de noeuds. Il peut prendre en charge les défaillances de la moitié des noeuds si le disque témoin reste en ligne. Par exemple, un cluster à 6 noeuds avec un disque témoin peut prendre en charge 3 défaillances de noeuds. Il peut également prendre en charge les défaillances de la moitié des noeuds moins 1 si le disque témoin est hors ligne ou en mode d’échec. Par exemple, un cluster à 6 noeuds avec un disque témoin en échec peut prendre en charge 2 défaillances de noeuds (3 – 1 = 2).

• Quorum de noeuds et de partages de fichiers majoritaire   Ce modèle est conçu pour les clusters avec des configurations spéciales et est recommandé pour les serveurs de boîtes aux lettres en cluster dans un environnement CCR. Ce modèle fonctionne de la même manière d’un modèle de noeuds et de disques majoritaire, mais utilise un partage de fichiers témoin plutôt qu’un disque témoin.

• Aucune majorité : disque seulement   Ce modèle, bien que pris en charge, n’est pas recommandé. Il peut prendre en charge les défaillances de tous les noeuds moins 1.Toutefois, cette configuration n’est pas recommandée car le disque est un point unique de défaillance.

Réplication continue sur des réseaux de clusters redondants

Dans Exchange 2007 RTM, toute copie et amorçage de fichiers journaux de transactions dans un environnement CCR a lieu sur le réseau public. Les limites de cette configuration sont les suivantes :

• Lorsque le noeud passif n'est pas disponible pendant plusieurs heures, un nombre significatif de journaux doit être transféré. Le déplacement de ces journaux doit être aussi rapide que possible lorsque le noeud passif est disponible. En copiant les journaux sur le réseau public, leur déplacement entre en compétition ave le trafic client. Cela affecte le trafic client et ralentit la resynchronisation.

• Lorsque le réseau public subit une défaillance, le basculement est incomplet, et ce même si les données des journaux sont disponibles.

• Un réseau isolé pour les communications des journaux permet de sécuriser les données de messagerie sans utiliser le chiffrage et sans expérimenter ses altérations de performances associées.

• Des bourrasques de journaux peuvent se produire sous certaines circonstances. Lorsqu'elles se produisent, le système expérimente une charge de réplication élevée inhabituelle. Cette situation peut provoquer une insuffisance au niveau du client si les données des journaux doivent être communiquées sur le réseau utilisé pour communiquer avec les clients.

Tous ces problèmes ne se produisent pas avec la même fréquence. Toutefois, le premier problème se produit effectivement tous les cinq mois car les noeuds passifs sont mis hors ligne pour les activités normales de maintenance.

Exchange 2007 SP1 réduit les effets des problèmes évoqués ci-avant en permettant à l'administrateur de créer un ou plusieurs réseaux mixtes dans le cluster (par exemple, un réseau de clusters qui prend en charge le trafic d'interrogations du cluster interne et le trafic client) pour l'envoi de journaux. Exchange 2007 SP1 permet également à l'administrateur de spécifier un réseau spécifique pour l'amorçage.

La prise en charge de la copie de fichier journal sur un réseau mixte est configurée à l'aide d'une nouvelle cmdlet de l'environnement de ligne de commande Exchange Management Shell nommée Enable-ContinuousReplicationHostName. De même, cette fonctionnalité est désactivée à l'aide de la cmdlet Disable-ContinuousReplicationHostName. Quand un serveur de boîtes aux lettres en cluster existe dans un environnement de CCR, un administrateur peut exécuter la cmdlet Enable-ContinuousReplicationHostName sur les deux noeuds du cluster et spécifier des adresses IP et des noms d'hôte supplémentaires, qui seront ensuite créés dans les groupes de cluster dédiés associés à chaque noeud. Après l'exécution de cette tâche, le service de réplication Microsoft Exchange utilise le réseau nouvellement créé pour la copie de journaux peu après la réussite de la configuration et après confirmation que le nouveau réseau est opérationnel. Si plusieurs réseaux sont créés, le service de réplication Microsoft Exchange sélectionnera aléatoirement l'un d'entre eux. Si le réseau spécifié est indisponible, le service de réplication Microsoft Exchange commencera automatiquement par utiliser les autres réseaux de réplication ; si aucun réseau n'est disponible, il commencera par utiliser le réseau public pour l'envoi de journaux dans les 5 minutes. (La découverte du réseau du service réplication Microsoft Exchange se produit toutes les 5 minutes). Lorsque le réseau de réplication préféré est à nouveau disponible, le service de réplication Microsoft Exchange recommence à l'utiliser pour l'envoi des journaux. Pour plus d'informations sur ces cmdlets, consultez les rubriques Enable-ContinuousReplicationHostName et Disable-ContinuousReplicationHostName.

La prise en charge de l'amorçage sur un réseau de clusters redundant est configurée à l'aide de la commande Update-StorageGroupCopy , qui a été mise à jour dans Exchange 2007 SP1 pour inclure un nouveau paramètre appelé DataHostNames. Ce paramètre permet de spécifier le réseau en cluster à utiliser pour l'amorçage. Pour plus d'information sur les modifications de la cmdlet Update-StorageGroupCopy dans Exchange 2007 SP1, consultez la rubrique Update-StorageGroupCopy.

Après la création d'un réseau de clusters pour la réplication continue, vous pouvez utiliser la cmdlet Get-ClusteredMailboxServerStatus pour afficher des informations mises à jour sur les réseaux de clusters pour lesquels la réplication continue a été activée. Les nouvelles informations de la sortie incluent :

• OperationalReplicationHostNames:{Host1,Host2,Host3}

• FailedReplicationHostNames:{Host4}

• InUseReplicationHostNames:{Host1,Host2}

Pour plus d'information sur les modifications de la cmdlet Get-ClusteredMailboxServerStatus dans Exchange 2007 SP1, consultez la rubrique Get-ClusteredMailboxServerStatus.

Pour plus d'informations sur l'activation des réseaux de clusters pour la réplication continue sous Windows Server 2003, consultez la rubrique Procédure d'activation de réseaux de clusters redondants pour l'amorçage et l'envoi de journaux sous Windows Server 2003.

Pour plus d'informations sur l'activation des réseaux de clusters pour la réplication continue sous Windows Server 2008, consultez la rubrique Procédure d'activation de réseaux de clusters redondants pour l'amorçage et l'envoi de journaux sous Windows Server 2008.

Pour plus d'informations sur la désactivation des réseaux de clusters pour la réplication continue, consultez la rubrique Procédure de désactivation de la réplication continue pour un réseau de clusters.

améliorations de la création de rapports et de 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 la benne de transport. Pour plus d'informations sur les améliorations apportées à l’établissement de rapports et à la surveillance, consultez la rubrique Surveillance de la réplication continue.

Améliorations liées aux performances

Des 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 sont les suivantes :

• Réductions d'E/S sur les disques contenant des copies passives de 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 base de données est désormais conservé sur le noeud passif entre des lots d'activité de relecture du journal. La conservation du cache de base de données entre des lots 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 du noeud passif par rapport aux E/S de disque du noeud actif.

  Déplacement plus rapide des serveurs de bases de données entre des noeuds dans une environnement CCR   Ces améliorations permettent de déplacer des serveurs de boîtes aux lettres en cluster entre les noeuds en moins de deux minutes. Cela inclut des déplacements exécutés par un administrateur (à l'aide de la cmdlet Move-ClusteredMailboxServer), ainsi que des basculements gérés par le service de cluster. Pour exécuter des déplacements rapides dans un environnement CCR, les bases de données sont mises hors ligne sans purge du cache de la base de données. Dans un cluster à copie unique, le déplacement du serveur de boîtes aux lettes en cluster prend environ cinq minutes. Le vidage du cache de base de données se produit toujours avant le déplacement du serveur de boîtes aux lettres en cluster. Il s’agit un flux opportuniste qui permet aux clients de rester connectés à la base de données. Ce comportement réduit la durée d'indisponibilité d'un serveur de boîtes aux lettres déplacé vers un autre noeud.

  Durant le processus de basculement, l'ID d'événement 9868 est enregistré deux fois pour indiquer le statut de l'opération de vidage et l'ID d'événement 113 est enregistré pour indiquer le statut de la réplication. Ces événements sont similaires à ce qui suit :

  ID de l'événement : 9868 Source : MSExchangeIS Catégorie : Général Type : Informations Description : Tentative de vidage du cache pour le serveur « <Nom_serveur_boîtes_aux_lettres> » terminée avec échec de 0 groupe(s) de stockage pour atteindre la profondeur du point de contrôle désirée.

  ID de l'événement : 9868 Source : MSExchangeIS Catégorie : Général Type : Informations Description : Tentative de vidage du cache pour le serveur « <Nom_serveur_boîtes_aux_lettres> » terminée avec échec de 2 groupe(s) de stockage pour atteindre la profondeur du point de contrôle désirée.

  ID de l'événement : 113 Source : MSExchangeRepl Catégorie : Déplacement Type : Informations Description : Le vidage du cache de la banque d'informations avant le déplacement du serveur de boîte aux lettres en cluster « <Nom_serveur_boîtes_aux_lettres> » ne s'est pas achevé. Données : Groupe de stockage « <Nom_serveur_boîtes_aux_lettres>\<Nom_groupe_stockage> » : le début de profondeur de point de contrôle était 19 et la fin était 17. Groupe de stockage « <Nom_serveur_boîtes_aux_lettres>\<Nom_second_groupe_stockage> » : le début de profondeur de point de contrôle était 19 et la fin était 13.

améliorations de la benne de transport ;

Le conteneur de dépôt de transport est une fonction du rôle serveur de transport Hub. Le conteneur de dépôt de transport gère une file d'attente des messages récemment remis à des destinataires dont la boîte aux lettres est située sur un serveur de boîtes aux lettres en cluster dans un environnement CCR. Cette file d'attente dépend de la durée de conservation du courrier et de l'espace total utilisé. Lors d'un basculement qui n'est pas Lossless, le serveur de boîtes aux lettres en cluster interroge automatiquement chaque serveur de transport Hub dans le site Active Directory pour soumettre de nouveau le courrier présent dans la file d'attente de conteneur de dépôt de transport.

Dans Exchange 2007 SP1, la fonctionnalité de conteneur de dépôt de transport a été améliorée de la façon suivante :

• Prise en charge de LCR   Le conteneur de dépôt de transport prend désormais en charge les déploiements LCR. Contrairement à CCR, dans lequel la demande de nouvelle remise du conteneur de dépôt de transport est une fonction automatique du processus de récupération, le processus est manuel dans un environnement LCR. 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, la demande de nouvelle remise de la benne de transport se produit dans le cadre du processus d'activation.

• Statistiques du conteneur de dépôt de transport   Pour mieux informer l’administrateur avant la récupération d’un serveur dans lequel des fichiers journaux sont manquants, le conteneur de dépôt de transport a été amélioré et inclut des informations statistiques qui indiquent l’état actuel de tous les serveurs de transport Hub contenant des messages pour un groupe de stockage attribué. Ces statistiques incluent le nombre de messages, ainsi que l’âge du message le plus ancien, disponibles sur chaque serveur de transport Hub du site Active Directory. Vous pouvez accéder à ces statistiques à l'aide d'un nouveau paramètre de la cmdlet Get-StorageGroupCopyStatus appelé DumpsterStatistics. Lors de l’utilisation de cette nouvelle valeur, la sortie de la cmdlet Get-StorageGroupCopyStatus inclura les statistiques du conteneur de dépôt de transport de tous les serveurs de transport Hub accessibles, ainsi qu’une liste des serveurs de transport Hub non accessibles. Les serveurs accessibles seront répertoriés dans une structure à valeurs multiples appelée DumpsterStatistics, et les serveurs inaccessibles seront répertoriés en tant que chaîne à valeur multiple appelée DumpsterStatisticsNotAvailable, comme indiqué ci-après :

  DumpsterStatistics : {HUB1 (horodatage le plus ancien ; nombre d’éléments dans le conteneur de dépôt ; taille du conteneur de dépôt), HUB2 (horodatage le plus ancien ; nombre d’éléments dans le conteneur de dépôt ; taille du conteneur de dépôt), HUB3 (horodatage le plus ancien ; nombre d’éléments dans le conteneur de dépôt ; taille du conteneur de dépôt)}

  DumpsterStatisticsNotAvailable : {HUB4,HUB5}

  Dans l’exemple précédent, l’horodatage le plus ancien correspond à l’heure à laquelle le message a été reçu par le serveur de transport Hub, et non à l’heure à laquelle le message a été remis à l’origine au serveur de boîtes aux lettres.

  La cmdlet Get-StorageGroupCopyStatus inclut également une nouvelle structure à valeurs multiples appelée OutstandingDumpsterRequests, qui inclut les serveurs de transport Hub avec des demandes en attente et la période (haute–basse) pour celles-ci, comme illustré ci-après :

  OutstandingDumpsterRequests : {HUB1 (période_basse;période_haute), HUB5 (période_basse;période_haute)}

Améliorations de la console de gestion Exchange

Exchange 2007 SP1 inclut de nouveaux éléments dans l’interface utilisateur graphiques (GUI) dans la console de gestion Exchange conçus pour améliorer l’expérience de gestion et de configuration pour les serveurs de boîtes aux lettres en cluster. Ces améliorations sont les suivantes :

• Assistant Gestion de serveur de boîtes aux lettres en cluster   Cet assistant permet de déplacer, d'arrêter ou de démarrer un serveur de boîtes aux lettres en cluster dans un environnement CCR ou SCC. La fonctionnalité de déplacement et d’arrêt inclut également des champs de commentaire facultatif de l'administrateur qui lui permettent d’entrer la raison pour laquelle un serveur de boîtes aux lettres en cluster est déplacé ou arrêté. Cet assistant est équivalent aux cmdlets suivantes de l'environnement de ligne de commande Exchange :

  • Move-ClusteredMailboxServer

  • Stop-ClusteredMailboxServer

  • Start-ClusteredMailboxServer

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

  Notes

  Dans un environnement CCR, l’Assistant Mettre à jour la copie du groupe de stockage n’est disponible qu’à partir du noeud passif et l’Assistant Restaurer la copie du groupe de stockage n’est disponible qu’à partir du noeud actif.

• Onglet Serveur de boîtes aux lettres en cluster   Un nouvel onglet a été ajouté à la boîte de dialogue Serveur Propriétés pour les serveurs de boîtes aux lettres existant dans un cluster. Ces informations sont disponibles pour les environnements CCR et SCC. Ce nouvel onglet fournit des informations détaillées sur le serveur de boîtes aux lettres en cluster et permet à un administrateur de configurer la valeur de la propriété AutoDatabaseMountDial pour les serveurs de boîtes aux lettres en cluster dans un environnement CCR. La plupart des informations affichées sous le nouvel onglet sont également disponibles à l’aide de la cmdlet Get-ClusteredMailboxServerStatus. Pour plus d'informations sur le serveur de boîtes aux lettres en cluster, consultez la rubrique Propriétés du serveur > onglet Serveur de boîtes aux lettres en cluster.

• Page Réplication continue en cluster   Une nouvelle page a été ajoutée à la boîte de dialogue Groupe de stockage Propriétés pour les serveurs de boîtes aux lettres déployés dans un environnement CCR. La nouvelle page sur les propriétés fournit des informations détaillées sur l’état de la réplication continue dans le cluster. Pour plus d'informations sur la page Réplication continue en cluster, consultez la rubrique Propriétés du groupe de stockage > page Réplication continue en cluster.

Pour plus d'informations

Windows Server 2008 inclut plusieurs fonctionnalités qui ont été améliorées ou renommées. Pour plus d'informations sur les modifications de fonctionnalité entre Windows Server 2003 et Windows Server 2008, consultez la rubrique Modifications terminologiques.