Considérations relatives à la planification de clusters

 

Dernière rubrique modifiée : 2006-03-17

Lors de la planification de clusters Exchange 2003, il est important de prendre en compte les considérations suivantes. Elles s'appliquent aux clusters Exchange 2003 sous Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, Windows 2000 Advanced Server et Windows 2000 Datacenter Server :

• Utilisation d'ordinateurs dédiés à Exchange
• Solutions de stockage de cluster
• Considérations liées aux performances et à l'évolutivité
• Compatibilité matérielle des clusters
• Clusters dispersés sur le plan géographique
• Stratégie de récupération d'urgence des clusters

Les sections suivantes abordent ces considérations en détail.

Utilisation d'ordinateurs dédiés à Exchange

Outre Exchange 2003, vos clusters de serveurs peuvent exécuter d'autres applications. Cependant, si vous exécutez plusieurs applications sur le même nœud, les performances de vos serveurs virtuels Exchange peuvent s'en ressentir. Lorsque vous décidez de dédier des ordinateurs exclusivement à Exchange, prenez en compte les considérations suivantes :

• Si vous utilisez un cluster pour plusieurs applications, il est conseillé de dédier un nœud à chaque application et de veiller à ce qu'il y ait un nombre suffisant de nœuds passifs dans votre configuration.
• Si vous utilisez les clusters pour fournir des services Exchange à vos utilisateurs, il est recommandé d'exécuter uniquement Exchange 2003 sur les clusters et d'exécuter les autres applications sur des ordinateurs distincts.
• Pour de meilleurs résultats, un serveur virtuel Exchange ne doit pas basculer vers un nœud actif qui exécute une autre application.
• Les nœuds d'un cluster Exchange 2003 doivent impérativement être serveurs membres d'un domaine. Les clusters Exchange 2003 ne prennent pas en charge les nœuds de clusters comme contrôleurs de domaine ou serveurs de catalogue global.

Pour plus d'informations sur les performances des clusters Exchange 2003, voir la rubrique sur la gestion des clusters Exchange du Guide d'administration de Microsoft Exchange Server 2003.

Solutions de stockage de cluster

Ce guide n'a pas pour but de traiter de manière détaillée la sélection d'une solution de stockage de cluster. Toutefois, cette section fournit des stratégies et des recommandations d'ordre général sur la mise en place d'une solution de stockage de cluster.

La plupart des méthodes conseillées qui s'appliquent aux serveurs autonomes (sans clusters) s'appliquent également aux serveurs en clusters (par exemple, les solutions RAID et les solutions SAN). Pour obtenir des informations détaillées sur les solutions de stockage Exchange, voir la rubrique sur la Planification d'une solution de stockage principale fiable.

Pour obtenir des informations détaillées sur la sélection d'une méthode de stockage de cluster dans Windows Server 2003, voir la rubrique sur le choix d'une méthode de stockage de cluster.

Utilisation de disques durs distincts pour les fichiers journaux

Si les groupes de stockage d'un serveur virtuel Exchange sont configurés de manière à ce que les fichiers journaux soient sur un jeu de lecteurs physiques et les bases de données sur un autre, tous les lecteurs doivent être configurés comme ressources de disques au sein du même serveur virtuel Exchange. En d'autres termes, toutes les données doivent résider sur un disque partagé et toutes les ressources de disques physiques doivent faire partie du groupe de cluster Exchange. Cela permet aux fichiers journaux et aux bases de données du groupe de stockage de basculer sur un autre nœud si le serveur virtuel Exchange se déconnecte.

Remarque :

La Surveillance du système doit dépendre de toutes les ressources de disques physiques (lecteurs et points de montage de volumes) qui contiennent des données Exchange. De cette manière, la ressource Surveillance du système peut accéder aux données Exchange figurant sur les ressources de disques physiques du serveur virtuel Exchange. Si la Surveillance du système ne dépend pas de ces ressources, les ressources Exchange peuvent démarrer avant d'être autorisées à lire les données sur les ressources de disques physiques. Ceci peut causer l'erreur de bases de données Exchange suivante : -1022 Jet_errDiskIO. Pour plus d'informations sur l'erreur de base de données Exchange =1022, voir l'article 314917 de la Base de connaissances Microsoft sur la compréhension et l'analyse des erreurs de base de données Exchange -1018, -1019 et -1022.

Limitations relatives aux groupes de stockage

Exchange 2003 est limité à quatre groupes de stockage par serveur. Cette limitation est une limitation physique et s'applique également à chaque nœud d'un cluster. Cette limitation peut être une source de problèmes dans les configurations actives/actives mais est sans impact sur les configurations actives/passives.

Remarque :
La configuration de cluster actif/passif est vivement recommandée pour Exchange 2003. Pour en connaître la raison, voir la section sur les configurations de clusters dans la rubrique sur les Clustering Exchange Server 2003.

Pour expliquer pourquoi cette limitation relative aux groupes de stockage n'a une incidence que sur les clusters actifs/actifs, prenons l'exemple d'un cluster actif/actif à deux nœuds dans lequel un nœud contient deux groupes de stockage et l'autre trois groupes de stockage.

Configuration de cluster actif/actif à deux nœuds avec cinq groupes de stockage

Serveur virtuel Exchange (EVS)	État	Nom du groupe de stockage
Nœud 1 Serveur virtuel Exchange (EVS) 1	Actif	groupe de stockage 1, groupe de stockage 2, groupe de stockage 3
Nœud 2 EVS2	Actif	groupe de stockage 1, groupe de stockage 2

Dans ce tableau, le cluster Exchange inclut un total de cinq groupes de stockage. Si le serveur virtuel Exchange 2 sur le nœud 2 bascule sur le nœud 1, ce dernier ne peut pas monter les deux groupes de stockage car il aura dépassé la limite des quatre groupes de stockage. Par conséquent, le serveur virtuel Exchange 2 (EVS2) ne peut pas être en ligne sur le nœud 1. Si le nœud 2 est toujours disponible, le serveur virtuel Exchange 2 (EVS2) bascule de nouveau sur le nœud 2.

Remarque :

Pour des besoins de sauvegarde et de récupération, Exchange 2003 ne peut pas prendre en charge un groupe de stockage supplémentaire, appelé groupe de stockage de récupération. Cependant, ce groupe de stockage de récupération ne peut pas être utilisé à des fins de basculement sur un nœud de cluster. Pour plus d'informations sur les groupes de stockage de récupération, voir la rubrique sur les nouvelles fonctionnalités d'Exchange 2003 du Guide des opérations de récupération d'urgence de Microsoft Exchange Server 2003.

Limitations relatives aux lettres de lecteur

Avant de déployer votre cluster Exchange 2003, vérifiez que vous avez tenu compte de la contrainte Windows qui impose une limite de 26 lettres de lecteurs par serveur. Si vous avez l'intention de configurer la majorité des disques du serveur en tant que ressources de cluster partagées, la limitation des 26 lettres de lecteurs s'applique à l'ensemble du cluster, et pas uniquement aux différents nœuds. Quel que soit le nombre de nœuds dans le cluster, le nombre maximal de disques partagés est généralement limité à 22. La raison pour laquelle cette limite est 22 disques et non 26 disques tient au fait qu'un disque doit être réservé comme disque système sur chaque nœud et que deux disques supplémentaires sont normalement alloués aux lecteurs de disquettes et de CD‑ROM (ou de DVD).

Remarque :
Si les nœuds de votre cluster exécutent Windows Server 2003 Enterprise Edition ou Windows Server 2003 Datacenter Edition, vous pouvez utiliser des points de montage de volumes pour contourner la limitation des 26 lettres de lecteurs. Pour plus d'informations, voir la section sur les points de montage de volumes Windows Server 2003 plus loin dans cette rubrique.

Il est recommandé d'utiliser une lettre de lecteur pour les bases de données et une pour les fichiers journaux de chaque groupe de stockage. Dans un cluster à quatre nœuds comportant trois serveurs virtuels Exchange, vous pouvez avoir jusqu'à 12 groupes de stockage. Par conséquent, un cluster à quatre nœuds peut nécessiter plus de 22 lettres de lecteurs.

Les sections suivantes fournissent des informations sur la planification d'une solution de stockage de cluster sous les systèmes d'exploitation Windows Server 2003 ou Windows 2000.

Limitations relatives aux lettres de lecteurs sous Windows 2000

Dans certaines configurations de clusters à quatre nœuds exécutant Windows 2000 Datacenter Server, vous pouvez être amené à désactiver un ou plusieurs lecteurs pour faire de la place pour des disques partagés supplémentaires dans le cluster. Par exemple, vous pouvez avoir besoin de désactiver les lecteurs de CD-ROM et de DVD-ROM sur vos serveurs. Si vous atteignez le nombre maximal de disques partagés, vous risquez d'éprouver des difficultés à mapper les lecteurs en vue d'un accès partagé au réseau.

Remarque :
Windows 2000 ne prend pas en charge l'utilisation de points de montage de volumes (forme de disque logique). Par conséquent, vous ne pouvez pas utiliser de points de montage de volumes pour les disques partagés Exchange avec Windows 2000. Cependant, vous pouvez utiliser les points de montage de volumes pour les lecteurs locaux (par exemple les lecteurs de CD‑ROM ou de DVD).

La contrainte relative au nombre de lettres de lecteurs limite le mode de conception du groupe de stockage et de l'architecture de base de données pour un cluster Exchange. Les sections suivantes fournissent des exemples de méthodes d'optimisation de la fiabilité des données de votre cluster lorsque vous utilisez Windows Server 2003.

Configuration de disque avec trois groupes de stockage

La configuration présentée dans le tableau suivant est fiable : chaque groupe de stockage (groupe de stockage 1, groupe de stockage 2 et groupe de stockage 3) a un lecteur dédié à ses bases de données et un autre lecteur dédié à ses fichiers journaux. Un disque supplémentaire est utilisé pour le répertoire de file d'attente SMTP du serveur virtuel Exchange. Cependant, dans cette conception, vous êtes limité à trois groupes de stockage par serveur virtuel Exchange.

Architecture de cluster (3 nœuds actifs/1 nœud passif) avec trois serveurs virtuels Exchange, comportant chacun trois groupes de stockage

Nœud 1 (EVS1 actif)	Nœud 2 (EVS2 actif)	Nœud 3 (EVS3 actif)	Nœud 4 (passif)
Disque 1 : SMTP/MTA	Disque 8 : SMTP	Disque 15 : SMTP	Disque 22 : Quorum
Disque 2 : bases de données du groupe de stockage 1	Disque 9 : bases de données du groupe de stockage 1	Disque 16 : bases de données du groupe de stockage 1
Disque 3 : journaux du groupe de stockage 1	Disque 10 : journaux du groupe de stockage 1	Disque 17 : journaux du groupe de stockage 1
Disque 4 : bases de données du groupe de stockage 2	Disque 11 : bases de données du groupe de stockage 2	Disque 18 : bases de données du groupe de stockage 2
Disque 5 : journaux du groupe de stockage 2	Disque 12 : journaux du groupe de stockage 2	Disque 19 : journaux du groupe de stockage 2
Disque 6 : bases de données du groupe de stockage 3	Disque 13 : bases de données du groupe de stockage 3	Disque 20 : bases de données du groupe de stockage 3
Disque 7 : journaux du groupe de stockage 3	Disque 14 : journaux du groupe de stockage 3	Disque 21 : journaux du groupe de stockage 3

Configuration de disque avec quatre groupes de stockage

La configuration présentée dans le tableau suivant ajoute un groupe de stockage supplémentaire. Cependant, pour rester dans la limite de 22 disques, les bases de données de chacun des quatre groupes de stockage (groupe de stockage 1, groupe de stockage 2, groupe de stockage 3 et groupe de stockage 4) de chaque serveur virtuel Exchange sont combinées sur deux disques. Les fichiers de base de données (.edb et .stm) des groupes de stockage 1 et 2 partagent un volume de disque et les fichiers de base de données des groupes de stockage 3 et 4 en partagent un autre. Cette configuration présente un avantage : elle permet d'utiliser l'ensemble des quatre groupes de stockage dans un cluster à quatre nœuds. Elle présente cependant un inconvénient : les volumes qui hébergent les bases de données des groupes de stockage partagés doivent avoir une capacité importante. Par conséquent, si un disque comportant une base de données tombe en panne, deux groupes de stockage au lieu d'un sont affectés.

Architecture de cluster (3 nœuds actifs/1 nœud passif) avec trois serveurs virtuels Exchange, comportant chacun quatre groupes de stockage

Nœud 1 (EVS1 actif)	Nœud 2 (EVS2 actif)	Nœud 3 (EVS3 actif)	Nœud 4 (passif)
Disque 1 : SMTP/MTA	Disque 8 : SMTP	Disque 15 : SMTP	Disque 22 : Quorum
Disque 2 : bases de données des groupes de stockage 1 et 2	Disque 9 : bases de données des groupes de stockage 1 et 2	Disque 16 : bases de données des groupes de stockage 1 et 2
Disque 3 : journaux du groupe de stockage 1	Disque 10 : journaux du groupe de stockage 1	Disque 17 : journaux du groupe de stockage 1
Disque 4 : journaux du groupe de stockage 1	Disque 11 : journaux du groupe de stockage 2	Disque 18 : journaux du groupe de stockage 2
Disque 5 : bases de données des groupes de stockage 3 et 4	Disque 12 : bases de données des groupes de stockage 3 et 4	Disque 19 : bases de données des groupes de stockage 3 et 4
Disque 6 : journaux du groupe de stockage 3	Disque 13 : journaux du groupe de stockage 3	Disque 20 : journaux du groupe de stockage 3
Disque 7 : journaux du groupe de stockage 4	Disque 14 : journaux du groupe de stockage 4	Disque 21 : journaux du groupe de stockage 4

Points de montage de volumes Windows Server 2003

Les points de montage des volumes sont désormais pris en charge sur les disques partagés lorsque les nœuds de votre cluster (quatre nœuds ou plus) exécutent Windows Server 2003 Enterprise Edition ou Windows Server 2003 Datacenter Edition. Les points de montage de volumes (également appelés points de jonction NTFS ou lecteurs montés) sont des répertoires qui pointent en permanence sur des volumes de disques spécifiés. (par exemple, vous pouvez configurer C:\Data pour qu'il pointe vers un volume de disque). Les points de montage de volumes n'ont pas besoin d'associer chaque volume de disque à une lettre de lecteur, ce qui permet de passer outre la limite des 26 lettres de lecteur.

Les points de montage sont utiles pour les clusters Exchange de grande capacité (par exemple, les clusters à quatre ou huit nœuds) qui ne peuvent pas offrir un nombre suffisant de lettres de lecteur pour des performances et une fiabilité optimales. Pour plus d'informations sur l'utilisation des points de montage pour limiter le nombre de lettres de lecteur, voir la rubrique sur l'exemple d'utilisation des clusters avec Exchange 2003.

Lors de l'installation de points de montage de volumes dans des clusters, tenez compte des recommandations suivantes :

• Veillez à créer des points de montage de volumes uniques de manière à ce qu'il n'y ait pas de conflit avec les lecteurs locaux existants sur les nœuds du cluster.
• Ne créez pas de points de montage de volumes entre des disques du périphérique de stockage du cluster (disques de cluster) et des disques locaux.
• Ne créez pas de points de montage des volumes à partir du disque de cluster qui contient la ressource de disque de quorum. Vous pouvez cependant créer un point de montage de volume de la ressource de disque de quorum vers un disque en cluster.
• Les points de volume de montage entre deux disques du cluster doivent se trouver dans le même groupe de ressource de cluster et dépendre du disque racine. En d'autres termes, le disque du point de montage de volume ne sera pas connecté sauf si le disque racine est connecté au préalable. La définition de cette dépendance empêche les délais et les défaillances au démarrage.

Il est conseillé d'utiliser les points de volume de montage avec des clusters Exchange 2003 à quatre nœuds ou plus. Utilisez un disque racine par groupe de stockage. Vous pouvez placer les journaux sur le disque racine et les bases de données sur le lecteur monté. Si vous manquez de lettres de lecteurs (comme c'est le cas dans un cluster à 8 nœuds), vous pouvez utiliser un seul disque racine. Cependant, dans le cas d'une défaillance du disque, pour limiter le risque de perte des données, ne stockez pas de données sur ce disque. Il faut un disque racine par serveur virtuel Exchange.

Pour plus d'informations sur la prise en charge des points de montage, voir l'article 318458 de la Base de connaissances Microsoft sur la prise en charge des points de montage de volume pour un cluster Exchange Server 2003 sur un système Windows Server 2003.

Pour plus d'informations sur l'ajout d'un point de montage de volume à un serveur virtuel Exchange, voir les ressources suivantes :

• Rubrique sur le déploiement d'Exchange 2003 dans un cluster du Guide de déploiement de Microsoft Exchange Server 2003
• Article 280297 de la Base de connaissances Microsoft sur la procédure pour configurer un point de montage de volume sur un serveur en cluster

Considérations liées aux performances et à l'évolutivité

Dans cette section, les aspects suivants des performances et de l'évolutivité des clusters de serveurs sont traités :

• Dimensionnement des clusters actifs/passifs
• Dimensionnement des clusters actifs/actifs
• Évolution verticale ou horizontale
• Test des composants serveur en clusters

Important :

La fragmentation de la mémoire virtuelle a une incidence négative sur les serveurs autonomes (sans utilisation de clusters). De même, la fragmentation de la mémoire virtuelle a une incidence négative sur les nœuds de clusters Exchange (surtout les nœuds de clusters actifs/actifs). Pour plus d'informations sur les réglages et contrôles permettant de gérer la fragmentation de la mémoire virtuelle dans un cluster, voir la rubrique sur la gestion des clusters Exchange du Guide d'administration de Microsoft Exchange Server 2003.

Pour plus d'informations sur les performances et l'évolutivité d'Exchange 2003, voir le Guide des performances et de l'évolutivité d'Exchange Server 2003.

Dimensionnement des clusters actifs/passifs

Vous devez définir la taille de vos clusters actifs/passifs comme vous le feriez pour des serveurs autonomes.

Remarque :

Avant de déployer vos serveurs en clusters, il est recommandé de tester les dimensionnements déterminés en laboratoire. Pour effectuer ces tests, vous pouvez utiliser des outils Exchange tels que LoadSim (Exchange Server Load Simulator 2003) et Jetstress. Pour plus d'informations sur l'importance des tests en laboratoire et les déploiements pilotes, voir la section correspondante dans la rubrique sur les Mesures de tolérance de pannes au niveau système.

Dimensionnement des clusters actifs/actifs

Les configurations de clusters actifs/actifs sont déconseillées pour les clusters Exchange. Toutefois, si vous décidez d'opter pour des clusters actifs/actifs, n'oubliez pas que Microsoft Exchange prend uniquement en charge les clusters actifs/actifs à deux nœuds. Cependant, dans le cas des clusters actifs/actifs, il existe deux contraintes importantes :

• Le nombre de connexions utilisateur simultanées par nœud ne doit pas dépasser 1 900. Si vous avez plusieurs serveurs virtuels Exchange par nœud, assurez‑vous que le total des connexions utilisateur MAPI simultanées est inférieur à 1 900.
• La charge UC moyenne par serveur ne doit pas dépasser 40 %.

Si ces contraintes ne sont pas respectées, vos utilisateurs pourront observer une baisse sensible des performances après un basculement. De plus, il est possible qu'un seul nœud du cluster actif/actif ne puisse pas mettre en ligne le second serveur virtuel Exchange.

Remarque :

Avant de déployer vos serveurs en clusters, il est recommandé de tester les dimensionnements déterminés en laboratoire. Pour effectuer ces tests, vous pouvez utiliser des outils Exchange tels que LoadSim (Exchange Server Load Simulator 2003) et Jetstress. Pour plus d'informations sur l'importance des tests en laboratoire et les déploiements pilotes, voir la section correspondante dans la rubrique sur les Mesures de tolérance de pannes au niveau système.

Considérations relatives à l'analyse des clusters actifs/actifs

Après avoir déployé votre cluster actif/actif, effectuez les tâches suivantes :

• Analysez la charge de l'unité centrale pour chaque nœud du cluster.
• Analysez le nombre de connexions (utilisateurs) simultanées par nœud.

Remarque :

Pensez à analyser ces valeurs durant des périodes d'utilisation maximale de la messagerie. De cette manière, si un basculement est nécessaire durant une période d'utilisation maximale de la messagerie, vous saurez si un seul nœud peut exécuter les deux serveurs virtuels Exchange. Par ailleurs, vous pouvez analyser un compteur manuellement en temps réel, ou vous pouvez l'utiliser pour compiler un rapport durant une période spécifiée (par exemple, durant une période de deux heures d'utilisation maximale de la messagerie).

Analyse de la charge de l'UC pour chaque nœud du cluster

Si la charge de l'UC dépasse 40 % (charge générée par les utilisateurs) pendant plus de 10 minutes, retirez des boîtes aux lettres du serveur. Cette charge n'inclut pas l'accroissement dû à des opérations administratives (telles que le déplacement des utilisateurs).

Pour analyser la charge de l'UC pour chaque nœud du cluster actif/actif, utilisez le compteur suivant de l'outil Analyseur de performances (Perfmon) :

Performances/%temps processeur/_Total

Remarque :
Ne vous préoccupez pas des pointes des performances de l'unité centrale. Normalement, la charge de l'unité centrale d'un serveur atteindra plus de 80 %, voire 90 %.

Contrôle des connexions simultanées (utilisateurs) par nœud

Si le nombre d'utilisateurs simultanés par nœud dépasse 1 900 pendant plus de 10 minutes, retirez des boîtes aux lettres du serveur virtuel Exchange. Bien qu'il vous soit possible de satisfaire cette exigence en identifiant simplement 1 900 boîtes aux lettres sur chaque serveur virtuel Exchange de votre cluster actif/actif, il est généralement préférable de contrôler le nombre d'utilisateurs MAPI simultanés par serveur, notamment parce que certains utilisateurs risquent d'établir plusieurs connexions à leurs boîtes aux lettres.

Pour contrôler le nombre d'utilisateurs simultanés par nœud, faites appel à l'un ou aux deux compteurs Perfmon suivants :

• MSExchangeIS/Nombre de connexions actives
• MSExchangeIS Boîte aux lettres(_Total)/Ouvertures de session client active

Remarque :
Ces compteurs donneront des résultats quelque peu différents et ne comptabiliseront pas les connexions Outlook Web Access de la même manière que les connexions Outlook. Pour comprendre l'utilisation du serveur, contrôlez les modifications apportées à ces compteurs au cours d'une journée de travail classique.

Évolution verticale ou évolution horizontale

Si vous étudiez la manière d'accueillir davantage d'utilisateurs (voire davantage de messages par utilisateur) dans votre environnement en clusters, vous pouvez envisager l'évolution verticale. Le processus d'évolution verticale a pour but d'utiliser des composants serveur plus puissants sur vos nœuds de cluster pour répondre à des demandes croissantes en matière de performances. Néanmoins, tandis que vous procédez à l'évolution verticale de votre matériel sur vos nœuds de cluster (par exemple, pour pouvoir héberger davantage d'utilisateurs sur chaque nœud), tenez compte surtout du fait que la disponibilité de chaque nœud augmente de manière significative.

La solution alternative à l'évolution verticale est l'évolution horizontale. Ce processus consiste à ajouter des nœuds à un cluster.

Pour expliquer ces deux options, imaginez une organisation hébergeant 3 000 utilisateurs sur un cluster à quatre nœuds. Le cluster présente trois nœuds actifs (1 000 utilisateurs par nœud) et un nœud passif. Si le besoin d'accueillir 1 000 utilisateurs supplémentaires se fait ressentir, deux options s'offrent à cette organisation :

• Option 1 : Évolution verticale   Il s'agit plus précisément d'augmenter la quantité de RAM et de processeur sur chacun des nœuds de cluster, puis de répartir les 1 000 utilisateurs supplémentaires de manière égale sur les nœuds.
• Option 2 : Évolution horizontale   Elle consiste à ajouter un nœud supplémentaire au cluster. Cette option fait passer la configuration du cluster à cinq nœuds, soit quatre nœuds actifs hébergeant chacun 1 000 boîtes aux lettres.

Dans cet exemple, si un incident provoque la défaillance de l'un des serveurs, le choix de l'option 2 affecte moins d'utilisateurs. Par conséquent, au moment de déployer Exchange dans un cluster, envisagez l'évolution horizontale comme une étape inhérente à votre plan d'évolutivité.

L'évolution horizontale peut également accroître la tolérance de pannes de votre cluster Exchange. Par exemple, un cluster à quatre nœuds, 2 actifs/2 passifs, peut simultanément gérer un plus grand nombre de défaillances qu'un cluster à quatre nœuds, 3 actifs/1 passif. Pour plus d'informations sur les clusters actifs/passifs, voir la section correspondante dans la rubrique sur les Clustering Exchange Server 2003.

Test des composants serveur en clusters

Avant de déployer vos serveurs en clusters dans un environnement de production, il est primordial que vous testiez leur capacité. Les outils utilisés pour tester le déploiement de clusters sont les mêmes que ceux utilisés dans le cadre de serveurs sans clusters (par exemple, LoadSim et Jetstress). Pour plus d'informations sur l'importance des tests en laboratoire et les déploiements pilotes, voir la section correspondante dans la rubrique sur les Mesures de tolérance de pannes au niveau système.

Voici la liste des éléments spécifiques à prendre en compte lors de tests liés aux clusters de serveurs.

Testez les composants matériels suivants :

• Composants d'ordinateur individuels tels que les disques durs, les contrôleurs, les processeurs et la mémoire vive (RAM)
• Composants externes tels que les routeurs, les passerelles, les commutateurs, le câblage et les connecteurs

Mettez sur pied les tests de stress suivants :

• Test des performances des clusters lors d'une charge réseau élevée
• Test des performances des clusters en cas de nombre élevé d'entrées/sorties sur le même disque
• Test des performances des clusters en cas de charges de services Exchange élevées
• Test des performances des clusters en cas de nombre élevé de tentatives d'ouverture de session simultanées
• Basculement de chaque serveur virtuel Exchange au moins une fois sur chaque nœud Le faire dans le cadre d'une charge de services Exchange élevée

Utilisez les résultats de ces tests pour :

• calculer le temps de réponse client pour la configuration du serveur sollicité ;
• estimer le nombre d'utilisateurs par serveur ;
• identifier les goulots d'étranglement sur le serveur.

Compatibilité matérielle des clusters

Dans le cas de Windows Server 2003 Enterprise Edition et Windows Server 2003 Datacenter Edition, Microsoft ne prend en charge que des systèmes de cluster de serveurs complets sélectionnés dans le catalogue Windows Server.

La prise en charge de composants système tiers est limitée en fonction des exigences requises des solutions tierces. Pour plus d'informations, voir l'article 814607 de la Base de connaissances Microsoft sur la prise en charge par Microsoft de clusters de serveurs avec des composants système tiers.

En règle générale, il est préférable d'utiliser le même matériel (par exemple, des processeurs identiques, des cartes d'interface réseau identiques et la même quantité de RAM) pour chaque nœud de cluster. Pour plus d'informations sur les raisons qui motivent une telle recommandation et justifient l'utilisation conseillée d'un matériel asymétrique dans vos nœuds de cluster, voir la section sur les configurations de clusters dans la rubrique sur les Clustering Exchange Server 2003.

Remarque :

Dans le cas d'un cluster dispersé sur le plan géographique, assurez-vous que la configuration matérielle et logicielle est certifiée et listée dans le catalogue Windows Server. Pour plus d'informations sur la compatibilité matérielle des clusters dispersés sur le plan géographique, voir la section sur les configurations adaptées aux clusters dispersés sur le plan géographique plus loin dans cette rubrique.

Pour plus d'informations sur les caractéristiques matérielles des clusters, voir l'article 309395 de la Base de connaissances Microsoft sur la stratégie de prise en charge par Microsoft des clusters de serveurs, la liste de compatibilité matérielle et le catalogue Windows Server.

Clusters dispersés sur le plan géographique

L'objectif principal d'un cluster dispersé sur le plan géographique est de s'assurer que la perte subie sur un site n'entraîne pas la perte de l'application tout entière. Les clusters dispersés sur le plan géographique offrent une disponibilité et une récupération accrues des services de messagerie Exchange (en revanche, les nœuds de cluster dans l'autre site de récupération ne fournissent pas de services Exchange, sauf en cas de défaillance d'un site). Qui plus est, en cas d'incident d'un site, les clusters dispersés sur le plan géographique garantissent la tolérance de pannes et le basculement des applications spécifiques employées. Nombre de solutions matérielles et logicielles garantissant une continuité commerciale tant au niveau du site que du cluster existent dans le cadre des clusters Exchange dispersés sur le plan géographique.

Au moment de planifier votre solution de cluster dispersé sur le plan géographique, assurez-vous que vous connaissez les réponses aux questions suivantes :

• Quels problèmes principaux mon cluster dispersé sur le plan géographique doit-il aborder ?
• Quelles sont les configurations adaptées à un cluster dispersé sur le plan géographique ?
• À quels besoins une solution de cluster dispersé sur le plan géographique doit-elle répondre en matière de solution de cluster ?
• Le reste de cette section fournit des informations détaillées sur chacune de ces questions.

Pour obtenir des informations d'ordre général sur la manière dont les clusters dispersés sur le plan géographique garantissent la tolérance de pannes de votre organisation Exchange 2003, voir la section sur l'utilisation de plusieurs sites physiques dans la rubrique sur les Mesures de tolérance de pannes au niveau système.

Problèmes qu'un cluster dispersé sur le plan géographique doit aborder

Un cluster dispersé sur le plan géographique doit répondre aux questions suivantes :

• Comment vous assurer que plusieurs sites disposent de copies indépendantes des mêmes données ? Comment les modifications de données sont-elles répliquées sur les sites ? Si des données sont modifiées sur un site et que le site en question est victime d'une défaillance, comment ces modifications sont-elles transmises aux sites restants ?
• Si un site tombe en panne, comment une application comme Exchange 2003 peut-elle garantir des services Exchange continus ?
• Comment vous assurer que vos clusters dispersés sur le plan géographique sont protégés contre tout risque de catastrophe naturelle ?

Résoudre ou non le premier problème n'a pas vraiment d'incidence pour la réplication des données en lecture seule d'un site physique à un autre. Vous pouvez aisément copier les données en lecture seule et une instance de ces données peut être hébergée sur chaque site. Pour résoudre le problème de la réplication des données, vous pouvez mettre en œuvre une réplication synchrone ou une mise en miroir du matériel et des logiciels. Ces techniques de réplication vous permettent de conserver des copies miroir mises à jour de chaque site physique.

Pour résoudre le deuxième problème, vous devez mettre en place une solution de cluster de basculement. Pour que cette solution puisse fonctionner, les nœuds de cluster sur les sites physiques distincts doivent apparaître aux yeux du service de cluster comme des éléments résidant sur le même réseau. Pour vous en assurer, vous pouvez recourir à des réseaux locaux virtuels (VLAN). Les réseaux locaux virtuels vous permettent de vous connecter à des emplacements physiques séparés sur de longues distances.

Enfin, pour résoudre le troisième problème, assurez-vous que l'espace qui sépare vos sites est suffisant pour éviter qu'une catastrophe naturelle éventuelle affecte plusieurs sites à la fois. Chaque site doit bénéficier d'une source d'alimentation complètement distincte et d'un fournisseur de communications qui lui est propre.

La figure suivante illustre un cluster dispersé sur le plan géographique de base adoptant ces solutions.

Configurations adaptées aux clusters dispersés sur le plan géographique

Un cluster dispersé sur le plan géographique désigne un ensemble de composants matériels et logiciels fournis par des fabricants d'équipements (OEM) et des éditeurs de logiciels. Les configurations de cluster dispersé sur le plan géographique de Microsoft Exchange 2003 peuvent s'avérer complexes et les clusters doivent exclusivement faire appel à des composants pris en charge par Microsoft. Les clusters dispersés sur le plan géographique doivent être uniquement déployés en association avec des fournisseurs offrant des configurations adaptées.

En règle générale, les restrictions appliquées aux clusters dispersés sur le plan géographique de Windows Server 2003 s'appliquent également à Exchange 2003. Pour obtenir des informations détaillées sur les clusters dispersés sur le plan géographique de Windows Server 2003, voir la rubrique sur les clusters dispersés sur le plan géographique dans Windows Server 2003.

Le matériel intervenant dans un cluster dispersé sur le plan géographique doit être adapté et répertorié dans la liste du matériel compatible de Microsoft. Pour obtenir une liste de compatibilité matérielle distincte répertoriant les clusters dispersés sur le plan géographique, voir le catalogue Windows Server.

Remarque :

Vous pouvez créer des clusters dispersés sur le plan géographique en ajoutant un logiciel de réplication des données ou du matériel de réseau local étendu aux configurations certifiées existantes. En revanche, ces solutions changent radicalement la nature de la configuration précertifiée, particulièrement en termes de synchronisation et de latence. Pour être prise en charge par Microsoft, la configuration matérielle et logicielle d'un cluster dispersé sur le plan géographique doit être certifiée et figurer dans la liste de compatibilité matérielle des clusters.

Pour plus d'informations sur la liste de compatibilité matérielle et les clusters Windows, voir l'article 309395 de la Base de connaissances Microsoft sur la stratégie de prise en charge par Microsoft des clusters de serveurs, la liste de compatibilité matérielle et le catalogue Windows Server.

Configuration technologique requise du service de cluster

Le logiciel Clustering Windows n'est pas conscient de la nature étendue des clusters dispersés sur le plan géographique. De manière plus précise, le service de cluster n'intègre aucune fonctionnalité propre aux configurations de cluster dispersé sur le plan géographique. C'est pourquoi l'architecture réseau et de stockage des clusters dispersés sur le plan géographique doit remplir les conditions suivantes :

• Les connexions aux réseaux public et privé doivent avoir lieu sur le même sous-réseau (réseau local non routé). Pour y parvenir, utilisez des réseaux locaux virtuels (VLAN) pour vous assurer que tous les nœuds de cluster apparaissent sur les mêmes sous-réseaux IP.

• Les connexions réseau doivent être capables de fournir une latence en boucle maximale garantie entre les nœuds d'au plus 500 millisecondes. Le cluster utilise les pulsations pour détecter si un nœud est actif ou ne répond pas. Ces pulsations sont transmises régulièrement (toutes les 1,2 secondes). Si un nœud prend trop de temps à répondre aux paquets de pulsations, le service de cluster lance un protocole à charge élevée pour distinguer les nœuds encore fonctionnels de ceux qui ne sont pas disponibles. On parle alors de regroupement des clusters.

• Si vous utilisez un quorum à nœud standard (également appelé quorum unique), le cluster doit être muni d'un disque partagé unique (appelé « disque quorum »).

  Remarque :
  Si vous exécutez Exchange 2003 sur Windows Server 2003, vous pouvez passer outre cette condition en utilisant le quorum Jeu de nœuds majoritaire. Pour plus d'informations sur les types de quorums, voir la section sur la ressource du disque quorum dans la rubrique sur les Clustering Exchange Server 2003.

  Pour faire apparaître un ensemble de disques sur deux sites distincts pour le service de cluster en tant que disque unique, l'infrastructure de stockage peut fournir une mise en miroir sur les sites. En revanche, elle doit préserver la sémantique fondamentale requise par la ressource de disque physique :

  • Le service de cluster fait appel aux commandes Reserve et à la réinitialisation du bus de l'interface SCSI (Small Computer System Interface) pour arbitrer et protéger les disques partagés. La sémantique de ces commandes doit être préservée sur l'ensemble des sites, même en cas de communication défaillante entre les sites. Si un nœud du Site A réserve un disque, les nœuds du Site B ne pourront pas accéder au contenu du disque. Pour éviter que les données des clusters et des applications ne soient corrompues, cette sémantique est primordiale.
  • Le disque quorum doit être répliqué en temps réel et en mode synchrone sur tous les sites. Les divers membres d'un disque quorum en miroir doivent disposer des mêmes données.

Stratégies de récupération d'urgence des clusters

Pour obtenir des informations sur les stratégies de récupération d'urgence propres aux clusters Exchange 2003, voir les rubriques sur la sauvegarde des clusters Exchange 2003 et la restauration des clusters Exchange 2003 dans le Guide des opérations de récupération d'urgence de Microsoft Exchange Server 2003.