Partager via

Installation de la réplication continue en cluster sur Windows Server 2008

  • Article

 

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

Dernière rubrique modifiée : 2008-12-19

Bien que le processus de déploiement de la réplication continue en cluster (CCR) sous Windows Server 2008 soit similaire au déploiement de la CCR sous Windows Server 2003, il y a quelques différences importantes. avant de déployer une CCR, il est recommandé de lire attentivement la rubrique Réplication continue en cluster. En outre, assurez-vous que vous satisfaites à toutes les exigences énoncées dans la rubrique Planification de la réplication continue en cluster.

L'installation de la CCR sous Windows Server 2008 se déroule en plusieurs phases :

  1. Configuration de l'installation du matériel, démarrage avec la formation et la configuration d'un réseau de clusters.

  2. Formation du cluster, d'abord le premier noeud, puis le deuxième.

  3. Configuration des réseaux de clusters et tolérance pour les interrogations de cluster manquées.

  4. Configuration et sécurisation du témoin de partage de fichiers.

  5. Installation des rôles serveur de boîtes aux lettres actif et passif dans le cluster. Le serveur de boîtes aux lettres en cluster (CMS) est créé lors de l'installation du rôle serveur de boîtes aux lettres actif.

    Notes

    Il est recommandé d'achever chaque phase avant d'entamer la suivante. Une fois toutes les phases accomplies, il est recommandé de vérifier la solution CCR avant de l'utiliser pour la production.

Certaines tâches consécutives à l'installation doivent également être exécutées :

  • réglage des paramètres de contrôle du basculement ;

  • réglage de la configuration par défaut du conteneur de dépôt de transport ;

  • vérification de la possibilité de déplacer un serveur de boîtes aux lettres en cluster entre les différents noeuds du cluster ;

  • activation de plusieurs réseaux pour une activité de réplication continue.

Avant d'exécuter l'une des procédures évoquées ci-après, vous devez commencer par vous assurer que les ordinateurs visés disposent des composants de système d'exploitation requis pour le système Windows Server 2008 installé. Pour obtenir la procédure détaillée d'installation des éléments préalables à l'installation de Microsoft Exchange sous Windows Server 2008, consultez la rubrique Procédure d'installation des éléments préalables d'Exchange 2007 SP1 et SP2 sous Windows Server 2008 ou Windows Vista.

Les sections suivantes décrivent chaque phase d'installation de façon plus détaillée.

Formation et configuration d'un réseau

Vous devez avoir un nombre suffisant d'adresses IP disponibles si vous créez des serveurs de boîtes aux lettres en cluster dans un environnement de réplication continue en cluster à deux noeuds sous Windows Server 2008. La fonctionnalité de cluster de 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, du protocole Internet DHCP (Dynamic Host Configuration Protocol) version 4 (IPv4) et d'IPv6. En cas d'exécution dans un cluster avec basculement Windows Server 2008, Microsoft Exchange Server 2007 Service Pack 1 (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 clusters à copie unique, ainsi que des serveurs de boîtes aux lettres dans un environnement de réplication continue en cluster.

Notes

Bien que DHCP IPv4 soit pris en charge dans les clusters avec basculement Windows Server 2008, il est recommandé d'utiliser des adresses IP statiques dans les environnements de production. Si DHCP IPv4 est utilisé dans un cluster avec basculement, il est recommandé de configurer les serveurs DHCP pour octroyer des baux de longueur illimitée.

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.

Toutes les adresses IP associées à une ressource de nom de réseau sont enregistrées de façon dynamique dans un DNS (Domain Name System) (si configuré pour des mises à jour dynamiques) avec la liste ordonnée de telle sorte que les ressources d'adresse IP en ligne sont renvoyées d'abord 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 ne sont plus applicables. Par conséquent, des organisations peuvent déployer un cluster de basculement entre deux centres de données physiques sans devoir utiliser la technologie LAN (VLAN) pour étendre les sous-réseaux de cluster entre les deux emplacements.

Les adresses IP sont requises pour les réseaux publics et privés. La configuration requise pour les adresses privées et publiques est la suivante :

  • Adresses privées   Chaque noeud requiert une adresse IP pour chaque carte réseau utilisée pour le réseau privé de clusters. Vous pouvez utiliser une adresse IPv4 statique ou une adresse IPv6 attribuée de façon dynamique. Vous ne devez pas utiliser d'adresses IP 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 des noeuds.

  • Adresses publiques   Chaque noeud requiert une adresse IP pour chaque carte réseau utilisée pour le réseau public en cluster, parfois appelé réseau mixte. Par ailleurs, des adresses IP sont requises pour le cluster de basculement 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 qui se trouvent sur le même sous-réseau ou réseau que l'un des réseaux privés. Vous pouvez utiliser des adresses IPv4 statiques, des adresses IPv4 DHCP ou une adresse IPv6 statique.

    Important

    Toutes les cartes réseau d'un réseau de clusters doivent utiliser la même version de TCP/IP, ce qui signifie qu'elles doivent toutes utiliser uniquement IPv4 ou IPv4 et IPv6.

Meilleures pratiques réseau pour les serveurs de boîtes aux lettres en cluster

Il est également recommandé de suivre les pratiques suivantes pour votre réseau en cluster :

  • Utilisation de noms significatifs   La création d'un cluster vous fournit de nombreuses occasions de donner des noms significatifs aux noeuds de cluster, aux interfaces réseau en cluster, aux clusters et aux serveurs de boîtes aux lettres en cluster. Par exemple, le réseau utilisé pour communiquer avec d'autres serveurs et clients Exchange peut s'appeler Public. Le réseau utilisé pour communiquer entre les noeuds de cluster peut s'appeler Privé. Attribuez des noms de façon à ne pas devoir se référer à une carte topologique. Une autre convention utile consiste à associer les noeuds d'un cluster au nom du serveur de boîtes aux lettres en cluster. Par exemple, utilisez mbx01, mbx01-node1 et mbx01-node2, respectivement pour le serveur de boîtes aux lettres en cluster et les deux noeuds.

  • Utilisation d'adresses IP privées pour les interfaces réseau privé   Pour obtenir la liste des plages d'adresses IP et des masques de sous-réseau utilisables pour les interfaces réseau privé sur chaque noeud, consultez le tableau suivant.

    Plages d'adresses et masques de sous-réseau pour les interfaces de réseau privé

    Réseau / Noeud Plage d'adresses IP Masque de sous-réseau

    Privé / NOEUD1

    10.10.10.10-255

    255.255.255.0

    Privé / NOEUD2

    10.10.10.11-255

    255.255.255.0

Considérez les informations suivantes :

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

  • Il n'est pas recommandé d'utiliser un type quelconque de carte tolérante aux pannes ou de groupement pour le réseau privé. Si vous avez besoin d'une redondance pour votre réseau privé, utilisez plusieurs cartes réseau configurées uniquement pour l'usage du cluster. Avant d'utiliser cette technologie, il est important de vérifier que vos microprogramme et pilote sont les plus récents. Pour plus d'informations sur la compatibilité sur un cluster de serveurs, contactez votre fabricant de carte réseau. Pour plus d'informations sur l'utilisation d’un groupement de cartes réseau dans des déploiements de clusters avec basculement, consultez l'article 254101 de la Base de connaissances Microsoft relatif à l'analyse de carte réseau et le clustering de serveur.

Formation du cluster de basculement

Un cluster avec basculement est formé lorsque le premier noeud est ajouté au cluster. Grâce à ce processus, le cluster dispose d'un nom de réseau et d'une adresse IP de réseau uniques. Le nom de réseau et l'adresse IP, qui forment ensemble l'identité réseau du cluster, se déplacent entre les noeuds du cluster à mesure que ceux-ci sont mis en ligne et hors connexion. Généralement, l'identité réseau du cluster est rarement utilisée dans l'administration d'un serveur de boîtes aux lettres en cluster.

Si vous êtes habitué à déployer des clusters avec basculement ou des clusters Exchange à partir de versions précédentes, vous trouverez que le déploiement d'un cluster pour une solution de CCR est une opération très différente. Si les solutions de cluster sont pour vous une nouveauté, vous constaterez que le déploiement est une opération beaucoup moins complexe qu'une configuration de cluster classique.

Vous pouvez créer un cluster en suivant les instructions énoncées dans la rubrique Procédure de création d'un cluster de basculement Windows Server 2008 pour la réplication continue en cluster.

Ajout de noeuds

Après que vous aurez installé le service de cluster sur le premier noeud, il vous faudra moins de temps pour l'installer sur le deuxième noeud. Cela est dû au fait que le programme d'installation se base sur les paramètres de configuration de réseau définis sur le premier noeud pour configurer les paramètres réseau sur les autres noeuds. Avant d'ajouter et de configurer le deuxième noeud, vous devez valider la configuration du cluster. Vous pouvez vérifier que le service de cluster est en cours d'exécution et que le cluster est opérationnel en exécutant Cluster.exe group à partir d'une invite de commandes. Cette commande devrait produire un résultat similaire à celui ci-après.

C:\>cluster group
Listing status for all available resource groups:
Group                   Node            Status
------------------ ---------------      ------
Cluster Group         <NODEName>        Online

Il est également recommandé de vérifier si les journaux des événements contiennent des erreurs et des avertissements requérant votre attention avant de poursuivre. Pour obtenir la procédure détaillée d'ajout du second noeud au cluster, consultez la rubrique Procédure de création d'un cluster de basculement Windows Server 2008 pour la réplication continue en cluster.

Configuration de réseaux en cluster

Une fois que les deux noeuds ont été ajoutés au cluster, les composants de cluster suivants doivent être configurés. Plus particulièrement, vous devez configurer des réseaux pour un accès au cluster et au client, et les paramètres de tolérance pour les interrogations de cluster manquées. Il est également recommandé de renommer les réseaux de clusters à l'aide de noms plus significatifs.

Le tableau suivant détaille les options suivantes pour configurer les réseaux de clusters pour les pulsations de cluster.

Options de configuration de réseaux de clusters

Option Description

Autoriser le cluster à utiliser ce réseau (réseau privé)

N'activez cette option que si vous voulez que le service de cluster utilise uniquement ce réseau pour le trafic de communication de cluster inter-noeuds. Les clients ne peuvent pas se connecter au serveur de boîtes aux lettres en cluster via ce réseau.

Autoriser le cluster à utiliser ce réseau et autoriser les clients à se connecter via ce réseau (réseau mixte)

Activez ces deux options si vous voulez que le service de cluster utilise la carte réseau pour la communication inter-noeuds de cluster et la communication avec des clients externes. Le service de cluster utilise ce réseau pour la communication inter-noeuds, et les clients peuvent se connecter au serveur de boîtes aux lettres en cluster à l'aide de ce réseau.

Ne pas autoriser le cluster à utiliser ce réseau (réseau non géré)

N'activez cette option que si vous ne voulez pas utiliser le réseau dans le cluster, ou si vous voulez que le service de cluster gère le réseau. Le service de cluster ne peut pas utiliser ce réseau pour une communication inter-noeuds, et les clients ne peuvent pas se connecter au serveur de boîtes aux lettres en cluster à l'aide de ce réseau.

Les serveurs de boîtes aux lettres en cluster déployés dans un environnement de réplication continue en cluster requièrent au moins deux cartes réseau dans chaque noeud pour être pris en charge. Dans Exchange 2007 SP1, chaque réseau géré par le service de cluster et activé pour l'usage du cluster et les connexions clientes (par exemple, configuré comme réseau mixte) peut être utilisé pour des fonctions de réplication continue, y compris l'amorçage, l'envoi de journaux et le réamorçage. Pour ce faire, utilisez une nouvelle cmdlet d'Exchange 2007 SP1 nommée Enable-ContinuousReplicationHostName.

Notes

Une option pour la configuration de réseaux de clusters consiste à créer une configuration réseau préliminaire, puis à exécuter l'Assistant Validation de configuration dans l'outil Gestion du cluster de basculement avec uniquement les tests réseau sélectionnés (par exemple, ignorer les tests d'inventaire, de stockage et de configuration système). Si seuls les tests réseau sont exécutés, le processus ne dure pas longtemps. À l'aide d'un rapport de validation, vous pouvez apporter les corrections nécessaires à la configuration du réseau. Une fois le cluster entier configuré, il est recommandé de réexécuter l'Assistant Validation de configuration et de sélectionner tous les tests.

Configuration des paramètres de tolérance pour les interrogations de cluster manquées

Une fois les paramètres de communications de cluster et de priorité réseau configurés, il est recommandé de configurer les paramètres de tolérance spécifiques pour les interrogations de cluster manquées. Cette opération configure la surveillance de connectivité réseau du service de cluster entre les noeuds de cluster pour tolérer des interruptions mineures. Cela empêche les basculements en cas de panne de réseau brève. Il est recommandé de configurer des réseaux en cluster privés et mixtes sur tous les noeuds pour qu'ils rendent compte de 10 interrogations manquées. Ce niveau de paramétrage correspond à environ 12 secondes.

Pour obtenir la procédure détaillée de configuration des composants de réseau de clusters, consultez la rubrique Procédure de configuration de réseaux de clusters pour un cluster avec basculement.

Configuration des paramètres de TTL pour la ressource de nom de réseau du serveur de boîtes aux lettres en cluster

Il y a deux scénarios de déploiement dans lesquels l'utilisation des options d'interruption et de récupération implique une modification de l'adresse IP affectée au serveur de boîtes aux lettres en cluster :

  • lors du déploiement d'un serveur de boîtes aux lettres en cluster dans un environnement de sous-réseau multiple ;

  • lors de l'utilisation d'un cluster de secours pour récupérer un cluster défaillant.

Dans les deux scénarios, le nom du serveur de boîtes aux lettres en cluster ne change pas mais l'adresse IP affectée au serveur de boîtes aux lettres en cluster change. 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 de cinq minutes pour la ressource de nom de réseau du serveur de boîtes aux lettres en cluster.

Notes

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 également une valeur TTL de cinq minutes pour la ressource de nom de réseau du cluster.

Par défaut, le service de cluster utilise un paramètre de 20 pour la valeur de DNS TTL des ressources de nom de réseau. Bien que les outils de gestion de DNS puissent être utilisés pour ajuster manuellement la valeur de TTL pour le nom d'hôte directement dans la base de données DNS, la valeur dans la base de données DNS est remplacée et définie sur la valeur par défaut du service de cluster (20 minutes) à chaque actualisation de l'enregistrement de nom de réseau dans DNS. Une actualisation de l'enregistrement de nom de réseau dans DNS intervient chaque fois que le serveur de boîtes aux lettres en cluster est démarré, déplacé ou reconnecté suite à une défaillance ou un basculement.

Dans Windows Server 2008, une nouvelle propriété privée a été ajoutée aux ressources de nom de réseau dans des clusters de basculement. La nouvelle propriété est nommée HostRecordTTL et vous pouvez la configurer à l'aide de Cluster.exe.

Notes

La propriété n'est disponible que dans les clusters avec basculement Windows Server 2008. Une telle propriété est inexistante dans les clusters avec basculement Windows Server 2003. Pour les clusters avec basculement exécutant Windows Server 2003, la valeur par défaut de 20 minutes du service de cluster est toujours appliquée.

Pour obtenir la procédure détaillée de configuration des valeurs de DNS TTL pour la ressource de nom de réseau serveur de boîtes aux lettres en cluster à 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.

Configuration du quorum de cluster

Une fois les réseaux de cluster configurés, l'étape suivante consiste à configurer le cluster avec basculement pour utiliser un noeud et une ressource de quorum de fichiers majoritaire. Pour obtenir la procédure détaillée de configuration d'un cluster avec basculement pour utiliser le modèle de noeud et de quorum de partages de fichiers majoritaire, consultez la rubrique Procédure de configuration du quorum de nœuds et partages de fichiers majoritaire.

Validation du cluster avec basculement

Windows Server 2008 inclut le nouvel assistant Validation de configuration permettant de vérifier l'intégrité et la configuration d'un cluster de basculement. Il est recommandé d'exécuter l'Assistant avant d'installer Exchange 2007 dans le cluster. En exécutant cet assistant avant d'installer Exchange 2007, vous pouvez identifier et résoudre des problèmes de configuration du cluster susceptibles d'empêcher l'exécution de l'installation d'Exchange.

L'Assistant Validation de configuration inclut quatre groupes de tests conçus pour vérifier que le cluster présente la configuration nécessaire pour être pris en charge par Microsoft. Ces exigences s'ajoutent à l'exigence que la solution de cluster porte le logo de compatibilité Conçu pour Windows Server 2008.

Les quatre groupes de tests sont les suivants : inventaire, réseau, stockage et configuration système. Comme la CCR n'utilise pas de stockage partagé, il n'est pas nécessaire d'exécuter le groupe de tests Stockage. Si vous exécutez le groupe de tests Stockage sur un cluster avec basculement ne disposant pas de ressources de stockage en cluster, tel qu'un cluster avec basculement conçu pour la CCR, le groupe de tests Stockage échoue. Vous pouvez ignorer tout échec du groupe de tests Stockage en toute sécurité parce que l'absence de stockage partagé est attendue pour un cluster de basculement conçu pour la CCR.

Pour obtenir la procédure détaillée de validation du cluster avec basculement, consultez la rubrique Procédure de validation d'une configuration de cluster avec basculement.

Configuration et installation d'un serveur de boîtes aux lettres en cluster

Vous pouvez installer un rôle serveur de boîtes aux lettres sur un cluster en exécutant quelques opérations sur chaque noeud. Une fois le cluster formé et validé et après que vous l'avez configuré pour utiliser le quorum jeu de noeud majoritaire (MNS) avec le témoin de partage de fichiers, vous devez commencer par installer le rôle serveur de boîtes aux lettres sur le noeud actif. Pour obtenir la procédure détaillée d'installation du rôle serveur de boîtes aux lettres sur le noeud actif, consultez la rubrique Procédure d'installation du rôle de boîtes aux lettres en cluster actif dans un environnement de CCR sous Windows Server 2008.

Après avoir installé le rôle serveur de boîtes aux lettres et un serveur de boîtes aux lettres en cluster sur le noeud actif, puis vérifié la configuration du premier groupe de stockage, vous devez installer le rôle serveur de boîtes aux lettres sur le noeud passif. Pour obtenir la procédure détaillée d'installation du rôle serveur de boîtes aux lettres sur le noeud passif, consultez la rubrique Procédure d'installation du rôle serveur de boîtes aux lettres en cluster passif dans un environnement de CCR sous Windows Server 2008.

Après avoir installé le rôle serveur de boîtes aux lettres, vous pouvez régler les paramètres de basculement. Pour plus d'informations sur le réglage d'un basculement, consultez la rubrique Procédure de réglage des paramètres de montage et de basculement pour la réplication continue en cluster.

Tâches consécutives à l'installation

Une fois le rôle serveur de boîtes aux lettres installé sur les deux noeuds et un serveur de boîtes aux lettres en cluster créé, vous devez exécuter des tâches consécutives à l'installation. Ces tâches sont les suivantes :

  • activation de plusieurs réseaux pour une activité de réplication continue.

  • réglage des paramètres de contrôle du basculement ;

  • réglage de la configuration par défaut du conteneur de dépôt de transport ;

  • Vérification de la possibilité de déplacer un serveur de boîtes aux lettres en cluster entre les différents noeuds du cluster.

Activation de plusieurs réseaux pour une activité de réplication continue

Dans la version de publication (RTM) de Microsoft Exchange Server 2007, toutes les activités de copie et d'amorçage de fichier journal ont lieu sur le réseau public. Dans Exchange 2007 SP1, tout réseau de clusters configuré comme réseau mixte peut être activé pour une activité de réplication continue. Cette activité inclut un amorçage et réamorçage du groupe de stockage et un envoi de journal.

Dans Exchange 2007 SP1, seuls les réseaux de clusters désignés comme mixtes peuvent être activés pour la réplication continue. Un réseau mixte est tout réseau de clusters configuré pour un trafic de cluster (communication inter-noeud) et d'accès au client. Les réseaux de clusters configurés pour un accès au cluster mais pas pour un accès au client (parfois appelés réseaux privés) ne peuvent pas être activés pour la réplication continue.

La prise en charge de l'envoi de journal sur un réseau mixte est configurée à l'aide de la nouvelle cmdlet 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 réplication continue en cluster, un administrateur peut exécuter la cmdlet Enable-ContinuousReplicationHostName sur les deux noeuds du cluster et spécifier deux adresses IP et noms d'hôte. Une fois cette opération effectuée, le système sélectionne de façon aléatoire un réseau mixte pour la copie de journal après la réussite de la configuration et après vérification du caractère opérationnel du réseau mixte.

Pour obtenir la procédure détaillée d'activation des réseaux de clusters pour une activité de réplication continue, 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.

Notes

Outre le nom d'hôte, l'adresse IP et le groupe de clusters créés sur le cluster de basculement, chaque fois que vous exécutez la cmdlet Enable-ContinuousReplicationHostName, vous créez un compte d'ordinateur dans le domaine Active Directory contenant le serveur de boîtes aux lettres en cluster. Par défaut, dans Windows Server 2008, le nombre maximal de comptes d'ordinateur que peut ajouter un utilisateur auquel n'ont pas été délégués de privilèges d'administrateur de domaine ni octroyées les entrées de contrôle d'accès (ACE) Création d'objets ordinateur et Suppression d'objets ordinateur, est 10. Un administrateur Exchange exécutant fréquemment les cmdlets Enable-ContinuousReplicationHostName et Disable-ContinuousReplicationHostName et ne disposant pas de privilèges d'administrateur de domaine ou des ACE précitées pourrait atteindre rapidement la limite de 10. Il existe plusieurs solutions à ce problème décrites dans l'article 307532 de la Base de connaissances, Comment faire pour dépanner le compte de service de cluster lorsqu'il modifie des objets 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.

L'amorçage et le réamorçage dans un environnement de CCR s'effectue à l'aide de la cmdlet Update-StorageGroupCopy. Dans Exchange 2007 SP1, cette cmdlet a été étendue pour inclure un nouveau paramètre nommé DataHostNames. Ce paramètre est utilisé pour spécifier le réseau à utiliser pour l'amorçage et le réamorçage. La valeur est une liste de plusieurs valeurs de deux noms : soit un nom de domaine complet (FQDN), soit un nom d'hôte. L'un de ces noms doit identifier un noeud passif.

Réglage des paramètres de contrôle du basculement

La réplication continue en cluster inclut des attributs permettant de contrôler le comportement de basculement d'un serveur de boîtes aux lettres en cluster. Vous pouvez configurer ces attributs à l'aide de la cmdlet Set-MailboxServer. Ces attributs sont fournis afin que vous puissiez contrôler les deux algorithmes de décision suivants :

  • Algorithme 1   L'algorithme 1 contrôle si une base de données est montée au moment du basculement. Au moment du basculement, s'il apparaît que la base de données a perdu moins de journaux que les journaux configurés, elle est montée automatiquement. Il est possible de configurer le nombre acceptable de journaux perdus à l'aide d'une valeur appelée AutoDatabaseMountDial. Ce paramètre, représenté dans Active Directory par un attribut Exchange Server appelé msExchDataLossForAutoDatabaseMount, peut prendre trois valeurs : Lossless, Good Availability et Best Availability. Lossless correspond à aucune perte de journaux, Good Availability correspond à la perte de 3 journaux et Best Availability (paramètre par défaut) correspond à la perte de 6 journaux. Pour obtenir la procédure détaillée de configuration de ces valeurs, consultez la rubrique Procédure de réglage des paramètres de montage et de basculement pour la réplication continue en cluster.

  • Algorithme 2   L'algorithme 2 permet de déterminer s'il est plus important d'être en ligne avec des anciennes données que d'être hors connexion. Si le montage de la base de données sur la base de l'algorithme 1 échoue, vous pouvez fixer le laps de temps après lequel effectuer une deuxième vérification. Le temps d'attente est configuré par l'attribut ForcedDatabaseMountAfter. La valeur est exprimée en unités d'heures et la valeur par défaut est illimitée.

    Important

    Une fois la valeur de ForcedDatabaseMountAfter atteinte, la base de données est montée, indépendamment du fait que la copie du groupe de stockage soit en retard d'un journal, de dix journaux ou de 1 000 journaux, ce qui pourrait entraîner une perte de données significative. C'est pourquoi ce paramètre ne doit pas être utilisé si les contrats de niveau de service (contrats SLA) garantissent un maximum sur le volume de la perte de données qui peut être encourue.

Réglage du conteneur de dépôt de transport

Le conteneur de dépôt de transport est une fonctionnalité du rôle serveur de transport Hub qui doit être configurée dans le cadre de l'utilisation de la réplication continue locale (LCR) ou de la CCR. Cette fonctionnalité est utilisée uniquement par les environnements de LCR et de CCR. Le conteneur de dépôt de transport soumet les messages récemment remis suite à une interruption non programmée. Le conteneur de dépôt de transport doit toujours être activé lors de l'utilisation de la LCR ou de la CCR. Le conteneur de dépôt de transport est activé à l'échelle de l'organisation en définissant la quantité de stockage disponible par groupe de stockage et le temps pendant lequel conserver les messages dans le conteneur de dépôt de transport.

Le serveur de transport Hub gère une file d'attente des messages récemment remis à un serveur de boîtes aux lettres en cluster. Dans l'hypothèse d'un basculement entraînant des pertes, la CCR demande automatiquement à chaque serveur de transport Hub du site de soumettre de nouveau les messages de la file d'attente du conteneur de dépôt de transport. Dans les environnements de LCR, la demande de nouvelle soumission est effectuée dans la cadre de la tâche Restore-StorageGroupCopy. Lors de la nouvelle soumission, la banque d'informations supprime automatiquement les doublons et remet de nouveau les messages perdus. La cmdlet Set-TransportConfig permet de modifier les paramètres de configuration par défaut du conteneur de dépôt de transport qui sont appliqués au niveau du groupe de stockage. De la même façon, dans Exchange 2007 SP1, vous pouvez également utiliser la console de gestion Exchange pour configurer les valeurs du conteneur de dépôt de transport.

Il est recommandé de configurer la taille maximale par groupe de stockage (le paramètre MaxDumpsterSizePerStorageGroup) sur une valeur équivalant à 1,5 fois la taille maximale de message pouvant être envoyé. Par exemple, si la taille maximale de message est 10 Mo, vous devez attribuer au paramètre MaxDumpsterSizePerStorageGroup la valeur 15 Mo. Pour les organisations ne définissant pas de taille maximale de message, il est recommandé de configurer le taille maximale par groupe de stockage sur une valeur équivalent à 1,5 fois la taille moyenne des messages envoyés dans l'organisation.

Il est également recommandé de configurer la période de rétention maximale par groupe de stockage (le paramètre MaxDumpsterTime) sur une valeur de 07.00:00:00, correspondant à 7 jours. Cela doit être suffisant pour éviter toute perte de messages en cas de panne prolongée. En cas d'utilisation de la fonctionnalité de conteneur de dépôt de transport, un espace disque supplémentaire est nécessaire sur le serveur de transport Hub pour héberger les files d'attente du conteneur de dépôt de transport. La quantité d'espace de stockage requise est plus ou moins égale à la valeur de MaxDumpsterSizePerStorageGroup multipliée par le nombre de groupes de stockage sur les serveurs de boîtes aux lettres utilisant la réplication continue dans le site Active Directory contenant le serveur de transport Hub.

Pour obtenir la procédure détaillée d'activation et de configuration du conteneur de dépôt de transport, consultez la rubrique Procédure de configuration de la benne de transport.

Vérification de la solution CCR

Après l'installation d'une solution de réplication continue en cluster ou l'apport de modifications de configuration importantes, il est recommandé de vérifier que les deux noeuds sont correctement configurés pour prendre en charge le serveur de boîtes aux lettres en cluster, ainsi que l'intégrité et l'état du serveur de boîtes aux lettres en cluster.

L'exécution des cmdlets Test-ReplicationHealth, Get-StorageGroupCopyStatus et Get-ClusteredMailboxServerStatus est la manière recommandée pour vérifier l'intégrité et l'état du serveur de boîtes aux lettres en cluster :

  • La cmdlet Test-ReplicationHealth est nouvelle dans Exchange 2007 SP1. Cette cmdlet est conçue pour exercer une surveillance proactive de la réplication continue et du pipeline de réplication continue. La cmdlet Test-ReplicationHealth vérifie tous les aspects de la réplication, des services de cluster et l'état de réplication et de relecture du groupe de stockage pour donner une vue d'ensemble complète du système de réplication. Pour plus d'informations sur la cmdlet Test-ReplicationHealth, consultez la rubrique Test-ReplicationHealth.

  • La cmdlet Get-StorageGroupCopyStatus fournit des informations sur l'état de réplication actuel pour chaque groupe de stockage. Pour obtenir la procédure détaillée d'affichage de l'état des groupes de stockage dans un environnement de CCR, consultez la rubrique Procédure d'affichage de l'état d'une copie de réplication continue en cluster à l'aide d'Exchange Management Shell.

  • La cmdlet Get-ClusteredMailboxServerStatus fournit un état opérationnel de base pour le serveur de boîtes aux lettres en cluster. Pour plus d'informations sur l'obtention de l'état opérationnel de base pour un serveur de boîtes aux lettres en cluster, consultez la rubrique Procédure d'affichage de l'état d'un serveur de boîtes aux lettres en cluster.

La méthode recommandée pour vérifier que les deux noeuds sont capables de mettre en ligne le serveur de boîtes aux lettres en cluster consiste à utiliser la cmdlet Move-ClusteredMailboxServer pour déplacer le serveur de boîtes aux lettres en cluster vers chaque noeud. Dans Exchange 2007 SP1, vous pouvez également utiliser l'Assistant Gestion de serveur de boîtes aux lettres en cluster de la console de gestion Exchange pour déplacer un serveur de boîtes aux lettres en cluster entre des noeuds afin de vérifier que ces derniers peuvent connecter le serveur de boîtes aux lettres en cluster.