Mesures de tolérance de pannes au niveau système

 

Dernière rubrique modifiée : 2006-08-16

Cette section présente certaines considérations relatives au niveau système et des stratégies d'augmentation de la tolérance de pannes de votre organisation Exchange 2003. Plus spécifiquement, l'expression de niveau système fait référence à votre infrastructure Exchange 2003 et aux méthodes conseillées en matière d'implémentation de la tolérance de pannes dans cette infrastructure.

La figure suivante illustre une infrastructure Exchange 2003 fiable et répertorie les méthodes conseillées pour la maintenance d'un niveau élevé de tolérance de pannes.

Mesures de tolérance de pannes au niveau de l'infrastructure

Cette section décrit les méthodes d'intégration de la tolérance de pannes à chaque niveau de votre infrastructure Exchange 2003. Plus spécifiquement, elle contient des informations sur les sujets suivants :

• implémentation de pare-feu et de réseaux de périmètre ;
• garantie d'un accès fiable à Active Directory et au système DNS ;
• garantie d'un accès fiable aux serveurs Exchange frontaux ;
• configuration des serveurs virtuels de protocole Exchange ;
• implémentation d'une solution de stockage principale fiable ;
• implémentation d'une solution de clustering de serveurs ;
• implémentation d'une stratégie de contrôle ;
• implémentation d'une stratégie de récupération d'urgence.

Implémentation de pare-feu et de réseaux de périmètre

Il est préférable que la topologie Exchange 2003 inclue un réseau de périmètre et une architecture de serveurs frontaux et principaux. La figure suivante illustre cette topologie, y compris la sécurité additionnelle fournie par un serveur proxy inversé avancé (ici, Internet Security and Acceleration (ISA) Server 2000 Feature Pack 1).

Remarque :

Pour améliorer les performances et l'évolutivité de votre serveur proxy inversé avancé, vous pouvez implémenter la fonctionnalité d'équilibrage de la charge réseau de Windows Server 2003 sur les serveurs de votre réseau de périmètre. Pour plus d'informations sur l'équilibrage de la charge réseau, voir « Utilisation de l'équilibrage de la charge réseau sur vos serveurs frontaux » plus loin dans cette rubrique.

Le déploiement d'ISA Server 2000 Feature Pack 1 dans un réseau de périmètre est un moyen parmi d'autres de renforcer la sécurité de votre système de messagerie. Vous pouvez également utiliser une sécurité de niveau transport telle que la sécurité IPSec (Internet Protocol Security) ou le protocole SSL (Secure Sockets Layer).

Important :
Que vous décidiez ou non d'implémenter une topologie incluant des serveurs frontaux Exchange 2003, il est déconseillé d'autoriser les utilisateurs Internet à accéder directement à vos serveurs principaux.

Pour des informations plus complètes sur la conception d'une topologie Exchange sécurisée, voir la rubrique sur la planification d'une infrastructure du guide Planification d'un système de messagerie Microsoft Exchange Server 2003.

Pour plus d'informations sur l'utilisation d'ISA Server 2000 avec Exchange 2003, voir la rubrique sur l'utilisation d'ISA Server 2000 avec Exchange Server 2003.

Garantie d'un accès fiable à Active Directory et au système DNS

Exchange dépend étroitement de Microsoft Active Directory et du système de noms de domaine (DNS). Pour garantir un accès fiable et efficace à Active Directory et au système DNS, assurez‑vous que vos contrôleurs de domaine, serveurs de catalogue global et serveurs DNS sont correctement protégés contre toute défaillance possible.

Contrôleurs de domaine

Un contrôleur de domaine est un serveur qui héberge une base de données de domaine et effectue les services d'authentification requis pour l'ouverture de session des clients et leur accès à Exchange (les utilisateurs doivent pouvoir être authentifiés par Exchange ou par Windows). Exchange 2003 repose sur les contrôleurs de domaine pour les informations de configuration des serveurs et du système. Dans Windows Server 2003, la base de données du domaine fait partie de la base de données Active Directory. Dans une forêt de domaines Windows Server 2003, les informations Active Directory sont répliquées entre des contrôleurs de domaine qui hébergent également une copie de la configuration de la forêt et des conteneurs de schémas.

Un contrôleur de domaine peut jouer de nombreux rôles dans une infrastructure Active Directory : il peut être serveur de catalogue global, maître d'opérations ou simple contrôleur de domaine.

Serveurs de catalogue global

Un serveur de catalogue global est un contrôleur de domaine qui héberge le catalogue global. Ce serveur de catalogue global est indispensable pour l'ouverture de session, car il contient des informations relatives à l'appartenance au groupe universel. En fonction de son appartenance à ce groupe, un utilisateur peut se voir autoriser ou refuser l'accès à des ressources. Si un serveur de catalogue global ne peut pas être contacté, il est impossible de déterminer l'appartenance d'un utilisateur au groupe universel, et l'accès en ouverture de session lui est refusé.

Remarque :

Bien que Windows Server 2003 comporte des fonctionnalités qui ne nécessitent pas de serveur de catalogue global local, vous devez prévoir un serveur de catalogue global local pour Exchange et Outlook. Le serveur de catalogue global est indispensable pour les services Exchange (notamment l'ouverture de session, l'appartenance à un groupe, les services de banque d'informations de Microsoft Exchange) et l'accès à la liste d'adresses globale (GAL). Le déploiement de serveurs de catalogue global en mode local pour les serveurs et les utilisateurs permet d'améliorer l'efficacité des recherches d'adresses. L'utilisation d'une connexion lente pour contacter un serveur de catalogue global augmente le trafic réseau et nuit à l'expérience de l'utilisateur.

Installez au moins un serveur de catalogue global dans chaque domaine contenant des serveurs Exchange.

Méthodes conseillées pour les contrôleurs de domaine et les serveurs de catalogue global

Dans la mesure où les contrôleurs de domaine contiennent des informations Active Directory essentielles, assurez‑vous que les contrôleurs de domaine de votre organisation sont correctement protégés contre toute défaillance éventuelle.

La liste suivante présente les méthodes conseillées concernant le déploiement et la configuration des contrôleurs de domaine Active Directory ainsi que des serveurs de catalogue global :

• N'exécutez pas Exchange 2003 sur vos contrôleurs de domaine, sauf si cela est indispensable pour votre organisation. Pour plus d'informations sur l'incidence de l'exécution de Microsoft Exchange sur un contrôleur de domaine, voir « Exécution de Microsoft Exchange 2003 sur un contrôleur de domaine » plus loin dans cette rubrique.

• Placez au moins deux contrôleurs de domaine dans chaque site Active Directory. Si un contrôleur de domaine n'est pas disponible dans un site, Exchange recherche alors un autre contrôleur de domaine. Ceci est particulièrement important si vous pouvez accéder aux autres contrôleurs de domaine de votre organisation uniquement via un réseau étendu. Cette circonstance peut générer des problèmes de performances et introduire éventuellement un point de défaillance unique.

• Placez au moins deux serveurs de catalogue global dans chaque site Active Directory. Si un serveur de catalogue global n'est pas disponible dans un site, Exchange recherchera un autre serveur de catalogue global. Ceci est particulièrement important si vous pouvez accéder aux autres serveurs de catalogue global de votre organisation uniquement via un réseau étendu. Cette circonstance peut générer des problèmes de performances et introduire éventuellement un point de défaillance unique.

  Remarque :
  Si la bande passante de deux contrôleurs de domaine et de deux serveurs de catalogue global par domaine n'est pas indispensable pour vos performances, vous pouvez configurer tous vos contrôleurs de domaine en tant que serveurs de catalogue global. Dans ce scénario, chaque contrôleur de domaine sera en mesure d'offrir des services de catalogue global à votre organisation Exchange 2003.

• En règle générale, il doit y avoir quatre processeurs Exchange pour un processeur de serveur de catalogue global, en supposant que les processeurs soient de modèle et de vitesse similaires. Cependant, un usage plus intensif des serveurs de catalogue global, une base de données Active Directory volumineuse ou des listes de distribution importantes peuvent nécessiter un plus grand nombre de serveurs de catalogue global.

• Dans les succursales qui desservent plus de 10 utilisateurs, il doit y avoir un serveur de catalogue global sur chaque site contenant des serveurs Exchange. Cependant, la meilleure solution consiste à déployer deux serveurs de catalogue global pour assurer la redondance. Si un site physique n'a pas deux serveurs de catalogue global, vous pouvez configurer des contrôleurs de domaine existants comme serveurs de catalogue global.

• Si votre architecture inclut plusieurs sous‑réseaux pour chaque site, utilisez au moins un contrôleur de domaine et un serveur de catalogue global pour chaque sous‑réseau afin de bénéficier d'une plu grande disponibilité. Par conséquent, même dans le cas d'une défaillance d'un routeur, vous pouvez accéder aux contrôleurs de domaine.

• Vérifiez que le serveur qui joue le rôle de maître d'infrastructure n'est pas un serveur de catalogue global. Pour plus d'informations sur le rôle de maître d'infrastructure, voir la rubrique « Catalogue global et maître d'infrastructure » dans l'aide de Windows 2000 Server.

• Vous pouvez contrôler la latence LDAP sur tous les contrôleurs de domaine Exchange 2003. Pour plus d'informations sur le contrôle d'Exchange, voir la rubrique sur l'Implémentation d'outils de contrôle logiciel et de détection d'erreurs.

• Vous pouvez faire passer le nombre de threads LDAP de 20 à 40, en fonction de vos besoins. Pour plus d'informations sur le réglage d'Exchange, voir le Guide des performances et de l'évolutivité d'Exchange Server 2003.

• Veillez à disposer d'un solide plan de sauvegarde pour vos contrôleurs de domaine.

Exécution de Microsoft Exchange 2003 sur un contrôleur de domaine

Dans la mesure du possible, évitez d'exécuter Exchange 2003 sur des serveurs qui font également office de contrôleurs de domaine Windows. Il est préférable de configurer les serveurs Exchange et les contrôleurs de domaine Windows séparément.

Toutefois, si votre organisation vous impose d'exécuter Exchange 2003 sur un contrôleur de domaine, prenez en considération les limitations suivantes :

• Si vous exécutez Exchange 2003 sur un contrôleur de domaine, il utilise uniquement le contrôleur de domaine en question. Par conséquent, en cas de défaillance du contrôleur de domaine, Exchange ne peut pas basculer sur un autre contrôleur de domaine.
• Si vos serveurs Exchange exécutent également des tâches de contrôleur de domaine en plus du service des ordinateurs clients Exchange, les performances des serveurs qui sont très sollicités par les utilisateurs peuvent se dégrader.
• Si vous exécutez Exchange 2003 sur un contrôleur de domaine, les responsabilités de vos administrateurs Active Directory et Exchange en matière de sécurité et de récupération d'urgence peuvent se recouper.
• Les serveurs Exchange 2003 qui font également office de contrôleurs de domaine ne peuvent pas faire partie d'un cluster Windows. Plus particulièrement, Exchange 2003 ne prend pas en charge les serveurs Exchange 2003 en clusters qui coexistent avec des serveurs Active Directory. Par exemple, dans la mesure où les administrateurs Exchange qui peuvent ouvrir une session sur le serveur local peuvent accéder au contrôleur de domaine par le biais de la console, ils ont la possibilité d'accroître leurs autorisations dans Active Directory.
• Si votre serveur est le seul contrôleur de domaine de votre système de messagerie, il doit également faire office de serveur de catalogue global.
• Si vous exécutez Exchange 2003 sur un contrôleur de domaine, évitez d'utiliser le commutateur /3GB, car le cache Exchange peut monopoliser la mémoire système. Qui plus est, puisque le nombre de connexions utilisateurs doit être faible, le commutateur /3GB ne devrait pas être nécessaire.
• Compte tenu que tous les services sont exécutés sous le compte LocalSystem, le risque d'exposition est plus élevé en cas de bogue au niveau de la sécurité. Par exemple, si Exchange 2003 est exécuté sur un contrôleur de domaine, un bogue Active Directory qui permet à un intrus d'accéder à Active Directory permet aussi à cet intrus d'accéder à Exchange.
• Le redémarrage ou l'arrêt d'un contrôleur de domaine qui exécute Exchange 2003 est très long (environ 10 minutes, voire plus). En effet, les services liés à Active Directory (par exemple, Lsass.exe) s'arrêtent avant les services Exchange. Par conséquent, les services Exchange échouent à plusieurs reprises lors de la recherche des services Active Directory. La première solution à ce problème consiste à modifier le délai d'attente d'un service défaillant. La seconde solution consiste à arrêter manuellement les services Exchange avant d'arrêter le serveur.

Disponibilité des services DNS et WINS (Windows Internet Name Service)

À l'instar des services de contrôleur de domaine et de serveur de catalogue global, les services DNS (Domain Name System) sont essentiels pour la disponibilité de votre organisation Exchange 2003. Sur un réseau Windows Server 2003, les utilisateurs ont recours aux services DNS et WINS (Windows Internet Name Service) pour localiser les ressources. L'échec d'un serveur DNS peut empêcher les utilisateurs de localiser votre système de messagerie.

Pour vous assurer que votre topologie Exchange 2003 inclut un accès fiable au système DNS, prenez en compte les éléments suivants :

• Vérifiez l'existence d'un serveur DNS secondaire sur le réseau. En cas de défaillance du serveur DNS principal, ce serveur secondaire doit pouvoir diriger les utilisateurs vers les serveurs appropriés.
• Intégrez des zones DNS Windows Server 2003 dans Active Directory. Dans ce scénario, chaque contrôleur de domaine devient un serveur DNS potentiel.
• Configurez chaque ordinateur client avec au moins deux adresses DNS.
• Dans la mesure du possible, configurez les deux serveurs DNS dans le même site que celui du client. Si les serveurs DNS ne sont pas dans le même site que le client, le serveur DNS principal doit être le serveur figurant dans le même site que le client.
• Vérifiez que la résolution des noms et le service DNS fonctionnent tous les deux correctement. Pour plus d'informations, voir l'article 322856 de la Base de connaissances Microsoft sur la procédure de configuration de DNS pour une utilisation avec Exchange Server.
• Avant de déployer Exchange, assurez‑vous que le service DNS est correctement configuré au niveau du concentrateur et de toutes les branches.
• Exchange requiert le service WINS. Bien qu'il soit possible d'exécuter Exchange 2003 sans activer le service WINS, cette configuration n'est pas recommandée. L'utilisation du service WINS pour la résolution de noms NetBIOS présente des avantages en termes de disponibilité (par exemple, dans certaines configurations, l'utilisation du service WINS élimine le risque potentiel de duplication des noms NetBIOS qui entraîne un échec de la résolution de noms). Pour plus d'informations, voir l'article 837391 de la Base de connaissances Microsoft sur Exchange Server 2003 et Exchange 2000 Server qui nécessitent une résolution de noms NetBIOS pour un fonctionnement optimal.

Pour plus d'informations sur le déploiement des services DNS et WINS, voir les rubriques sur le déploiement des services DNS et WINS dans le Kit de déploiement de Microsoft Windows Server 2003.

Garantie d'un accès fiable aux serveurs Exchange frontaux

Si votre organisation comporte plusieurs serveurs Exchange, il est recommandé d'opter pour une architecture de serveurs frontaux et principaux Exchange. Cette architecture offre plusieurs avantages en matière de disponibilité et de performances d'accès des clients.

Les clients Internet accèdent à leurs boîtes aux lettres via des serveurs frontaux. Toutefois, dans les configurations Exchange 2003 par défaut, les clients MAPI ne peuvent pas utiliser des serveurs frontaux ; ils accèdent à leurs boîtes aux lettres directement via des serveurs principaux.

Remarque :
Dans Exchange 2003, vous pouvez configurer la communication RPC sur HTTP pour que vos clients MAPI puissent accéder à leurs boîtes aux lettres via des serveurs frontaux. Pour plus d'informations sur l'utilisation de RPC sur HTTP, voir la rubrique sur les scénarios de déploiement RPC sur HTTP d'Exchange Server 2003.

Lorsque les serveurs frontaux utilisent le protocole HTTP, POP3 et IMAP4, les performances sont accrues car les serveurs frontaux déchargent les serveurs principaux d'une partie de leurs tâches de traitement de charge.

Si vous avez l'intention de prendre en charge MAPI, HTTP, POP3 ou IMAP4, vous pouvez utiliser l'architecture frontale/principale de Microsoft Exchange pour bénéficier des avantages suivants :

• Les serveurs frontaux équilibrent les tâches de traitement entre les différents serveurs. Les serveurs frontaux gèrent, par exemple, l'authentification, le cryptage et le décryptage, ce qui améliore les performances de vos serveurs principaux Exchange.
• La sécurité de votre système de messagerie est optimisée. Pour plus d'informations, voir « Mesures de sécurité » plus loin dans cette rubrique.
• Pour incorporer la redondance et l'équilibrage de charge dans votre système de messagerie, vous pouvez utiliser l'équilibrage de la charge réseau (NLB, Network Load Balancing) sur vos serveurs frontaux Exchange.

Pour plus d'informations sur la planification d'une architecture de serveurs frontaux et principaux Exchange 2003, voir la section sur la planification de votre infrastructure dans la rubrique sur la planification d'un système de messagerie Exchange Server 2003.

Pour plus d'informations sur le déploiement de serveurs frontaux et principaux, voir la rubrique sur l'utilisation des serveurs frontaux Microsoft Exchange 2000. Ce document traite de Microsoft Exchange 2000, mais son contenu s'applique aussi à Microsoft Exchange 2003.

Pour assurer la tolérance de pannes de votre système de messagerie, vous pouvez mettre en place des serveurs frontaux Exchange qui utilisent l'équilibrage de la charge réseau. Vous devez également configurer des serveurs virtuels redondants sur vos serveurs frontaux.

Utilisation de l'équilibrage de la charge réseau sur vos serveurs frontaux

L'équilibrage de la charge réseau est un service Windows Server 2003 qui prend en charge l'équilibrage de charge pour les applications et services basés sur le protocole IP nécessitant une évolutivité et des performances élevées. Lorsque le service d'équilibrage de la charge réseau est mis en place sur vos serveurs frontaux Exchange 2003, il permet de résorber les goulots d'étranglement causés par les services frontaux.

La figure suivante illustre une architecture frontale et principale simple qui inclut le service d'équilibrage de la charge réseau.

Un cluster d'équilibrage de charge réseau affecte de manière dynamique le trafic IP à deux serveurs frontaux Exchange (ou plus), répartit de manière transparente les requêtes des clients entre les serveurs frontaux, et autorise les clients à accéder à leurs boîtes aux lettres via un espace de noms unique sur le serveur.

Les clusters d'équilibrage de charge réseau sont des ordinateurs qui, de par leur nombre, optimisent l'évolutivité et les performances des applications et des ordinateurs suivants:

• Les serveurs Web
• Les ordinateurs exécutant ISA Server (pour les serveurs proxy et pare‑feu)
• Les autres applications qui reçoivent du trafic TCP/IP et UDP (User Datagram Protocol)

En règle générale, la configuration matérielle et logicielle est la même pour les différents nœuds de cluster d'équilibrage de charge réseau. Ainsi, les performances qu'offrent les services frontaux à vos utilisateurs sont harmonisées, quel que soit le nœud de cluster d'équilibrage de charge réseau qui assure le service. Les nœuds d'un cluster d'équilibrage de charge réseau sont tous actifs.

Important :
Les clusters d'équilibrage de charge réseau ne prennent pas en charge le basculement, contrairement au service de cluster Windows. Pour plus d'informations, voir la section suivante, « Équilibrage de la charge réseau et évolutivité ».

Pour plus d'informations sur l'équilibrage de la charge réseau, voir la rubrique sur la conception et le déploiement de l'équilibrage de la charge réseau du Kit de déploiement de Microsoft Windows Server 2003.

Équilibrage de la charge réseau et évolutivité

Dans le contexte de l'équilibrage de la charge réseau, au fur et à mesure que la demande augmente sur vos serveurs frontaux Exchange 2003, vous pouvez opter pour une évolution verticale ou pour une évolution horizontale. En général, si votre principal objectif est d'offrir un service plus rapide à vos utilisateurs Exchange, l'évolution verticale (par exemple l'ajout d'autres processeurs et d'un complément de mémoire) constitue une bonne solution. Cependant, si vous voulez appliquer des mesures de tolérance de pannes sur vos services frontaux, l'évolution horizontale (l'ajout de serveurs supplémentaires) constitue la meilleure solution. Avec l'équilibrage de la charge réseau, vous pouvez intégrer jusqu'à 32 serveurs si besoin est. L'évolution horizontale optimise la tolérance de pannes. En effet, si votre cluster d'équilibrage de charge réseau inclut un grand nombre de serveurs, la défaillance d'un serveur n'affecte que peu d'utilisateurs.

Important :

Vous devez contrôler attentivement les serveurs de votre cluster d'équilibrage de charge réseau. Lorsqu'un serveur d'un cluster d'équilibrage de charge réseau tombe en panne, les requêtes des clients qui étaient configurées pour être envoyées sur le serveur défaillant ne sont pas automatiquement distribuées aux autres serveurs du cluster. Par conséquent, lorsqu'un serveur de votre cluster d'équilibrage de charge réseau tombe en panne, il doit être retiré immédiatement du cluster pour que les services requis puissent être fournis à vos utilisateurs.

Configuration des serveurs virtuels de protocole Exchange

Lorsque vous configurez votre système de messagerie Exchange 2003, utilisez le Gestionnaire système Exchange afin de créer un serveur virtuel de protocole pour chaque protocole que vous souhaitez prendre en charge sur un serveur frontal spécifique.

Pour optimiser la disponibilité et les performances de vos serveurs frontaux, prenez en compte les recommandations suivantes lors de la configuration des serveurs virtuels de protocole :

• Lorsque vous configurez l'équilibrage de la charge réseau de vos serveurs frontaux Exchange 2003, vérifiez que tous les serveurs virtuels de protocole sur vos serveurs frontaux d'équilibrage de charge réseau sont configurés à l'aide de paramètres identiques.

  Important :
  Si les serveurs virtuels de protocole de votre cluster d'équilibrage de charge réseau ne sont pas identiques, vos clients de messagerie pourront observer un comportement différent, en fonction du serveur vers lequel ils sont routés.

• Si vous n'utilisez pas l'équilibrage de la charge réseau sur vos serveurs frontaux, ne créez aucun serveur virtuel de protocole supplémentaire sur vos différents serveurs frontaux (par exemple, ne créez pas deux serveurs virtuels de protocole HTTP identiques sur le même serveur frontal). La création d'autres serveurs virtuels peut entraîner une dégradation importante des performances, et vous devez créer ces serveurs uniquement lorsqu'il n'est pas possible de configurer correctement les serveurs virtuels par défaut.

Pour plus d'informations sur la configuration de serveurs virtuels de protocole Exchange, voir le Guide d'administration de Microsoft Exchange Server 2003.

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

Implémentation d'une solution de stockage principale fiable

Une stratégie de stockage fiable est essentielle pour garantir la tolérance de pannes d'un système de messagerie. Pour mettre en œuvre et configurer une solution de stockage fiable, vous devez maîtriser les éléments suivants :

• Technologie de base de données Exchange 2003
• Méthodes conseillées pour configurer et mettre à jour les données Exchange
• Technologies de stockage avancées telles que RAID et les réseaux de stockage (SAN, Storage Area Network)
• Pour obtenir des informations détaillées sur la planification et la mise en œuvre d'une solution de stockage principale fiable, voir la rubrique sur la Planification d'une solution de stockage principale fiable.

Implémentation d'une solution de clustering de serveurs

Dans la mesure où le clustering de serveurs autorisent le basculement des ressources, ils permettent d'assurer la tolérance de pannes de votre organisation Exchange 2003. Plus précisément, les clusters de serveurs qui utilisent le service de cluster gèrent l'intégrité des données et assurent le basculement et la disponibilité élevée des applications et des services importants de vos serveurs principaux, y compris les bases de données, les systèmes de messagerie et les services de fichiers et d'impression.

La figure suivante présente un exemple de cluster à quatre nœuds qui inclut trois nœuds actifs et un nœud passif.

Dans les clusters de serveurs, les nœuds partagent l'accès aux données. Les nœuds peuvent être actifs ou passifs, et la configuration de chaque nœud dépend du mode de fonctionnement (actif ou passif) ainsi que de la méthode de configuration du basculement. Dans le cas d'un serveur qui gère le basculement, sa taille doit être suffisamment importante pour qu'il puisse gérer la charge de travail du nœud défaillant.

Remarque :

Dans Windows Server 2003 Enterprise Edition et Windows Server 2003 Datacenter Edition, les clusters de serveurs peuvent contenir jusqu'à huit nœuds. Chaque nœud est associé à un ou à plusieurs périphériques de stockage de cluster, ce qui permet à différents serveurs de partager les mêmes données. Étant donné que les nœuds d'un cluster de serveurs partagent l'accès aux données, le type et la méthode de stockage du cluster de serveurs sont importants.

Pour plus d'informations sur la planification des clusters de serveurs Exchange, voir la rubrique sur la Planification des clusters Exchange.

Avantages du clustering

Le clustering de serveurs permet à votre organisation de bénéficier de deux avantages : le basculement et l'évolutivité.

Basculement

Le basculement est l'avantage principal du clustering de serveurs. En cas de défaillance d'un serveur d'un cluster, la charge de travail du serveur défaillant bascule sur un autre serveur du cluster qui prend le relais. Le basculement garantit la disponibilité continue des données et des applications. Les technologies de clustering Windows assurent une protection contre trois types de défaillances :

• Les défaillances des applications et des services : ces défaillances affectent des logiciels d'application et des services essentiels.
• Les défaillances système et matérielles : ces défaillances affectent les composants matériels tels que les unités centrales, les lecteurs, la mémoire, les cartes réseau et l'alimentation électrique.
• Les défaillances de site dans des organisations incluant plusieurs sites : ces défaillances peuvent être causées par des catastrophes naturelles, des pannes d'électricité ou des pannes de connexion. Pour vous protéger contre ce type de défaillance, vous devez mettre en œuvre une solution avancée de clusters dispersés sur le plan géographique. Pour plus d'informations, voir « Utilisation de plusieurs sites physiques » plus loin dans cette rubrique.

Dans la mesure où le clustering de serveurs assure une protection contre ces types de défaillances, il apporte les deux avantages suivants à votre environnement de messagerie :

• Une disponibilité élevée   Aptitude à garantir aux utilisateurs finals des services d'accès fiables tout en réduisant les pannes imprévues.
• Une fiabilité élevée   Aptitude à limiter la fréquence des défaillances système.

Évolutivité

L'évolutivité constitue un autre avantage du clustering de serveurs. Dans la mesure où vous pouvez ajouter des nœuds à vos clusters, les clusters de serveurs Windows sont extrêmement évolutifs.

Limitations du clustering

Le clustering de serveurs assure la tolérance de pannes au niveau des applications plutôt qu'au niveau des données. Lorsque vous adoptez une solution de clustering de serveurs, vous devez également mettre en œuvre des solutions de protection des données et de récupération fiables pour assurer la protection contre les virus, la corruption des données et d'autres menaces auxquelles les données peuvent être confrontées. Les technologies de clustering ne garantissent pas une protection contre les défaillances causées par les virus, la corruption des logiciels ou les erreurs humaines.

Différences entre le clustering et le matériel à tolérance de pannes

Le clustering et le matériel à tolérance de pannes protègent votre système contre les défaillances des composants (telles que les défaillances des unités centrales, de la mémoire, des ventilateurs ou des bus PCI). Bien qu'il soit possible d'adopter une solution « de bout en bout » qui associe le clustering et le matériel à tolérance de pannes, sachez que ces deux méthodes n'assurent pas la disponibilité élevée de la même manière :

• Le clustering peut vous protéger contre une défaillance d'une application ou d'un système d'exploitation. Cependant, un serveur autonome (n'appartenant pas à un cluster) qui utilise du matériel à tolérance de pannes (ou un serveur qui utilise du matériel échangeable à chaud permettant l'ajout d'un périphérique lors de l'exécution du serveur) ne peut pas garantir une protection contre ces types de défaillances.
• Le clustering vous permet d'effectuer des mises à niveau ou des installations sur l'un des nœuds du cluster tout en assurant une disponibilité totale des services Exchange pour les utilisateurs. Dans le cas des serveurs autonomes (n'appartenant pas à un cluster), vous devez souvent arrêter les services Exchange pour effectuer ces mises à niveau ou ces installations. Pour obtenir des informations spécifiques sur les méthodes permettant d'assurer la disponibilité des services Exchange lors de mises à niveau ou d'installations, voir la rubrique sur la déconnexion de serveurs virtuels ou de ressources Exchange dans le Guide d'administration d'Exchange Server 2003.

Implémentation d'une stratégie de contrôle

Il est essentiel de surveiller constamment votre réseau, vos applications, vos données et votre matériel pour garantir une disponibilité élevée. Les outils et les techniques de contrôle logiciel vous permettent de déterminer l'état général de votre système et d'identifier les problèmes éventuels avant qu'une erreur ne survienne.

Pour optimiser la disponibilité, vous devez en permanence gérer et analyser vos serveurs ainsi que vos applications, et également résoudre les problèmes rencontrés. En cas de problème, vous devez être en mesure de réagir rapidement afin de récupérer les données et de les rendre disponibles dès que possible. Pour faciliter le contrôle de votre organisation Exchange 2003, vous pouvez utiliser « Exchange 2003 Management Pack for Microsoft Operations Manager ».

Pour obtenir des informations complètes sur Exchange 2003 Management Pack, Microsoft Operations Manager et d'autres outils de contrôle, voir la rubrique sur l'Implémentation d'outils de contrôle logiciel et de détection d'erreurs.

Implémentation d'une stratégie de récupération d'urgence

Pour accroître la tolérance de pannes dans votre organisation, vous devez concevoir et mettre en place une stratégie de sauvegarde et de récupération soigneusement planifiée. Si vous êtes préparé, vous devriez pouvoir procéder à des récupérations pour la plupart des défaillances.

Autres méthodes conseillées de niveau système

À présent que vous avez étudié les mesures permettant d'accroître la tolérance de pannes dans votre infrastructure Exchange 2003, prenez connaissance des méthodes conseillées de niveau système suivantes :

• Protection de l'environnement physique des serveurs   Prenez des précautions pour vous assurer que l'environnement physique est protégé.
• Mesures de sécurité   Implémentez des méthodes d'autorisations, des correctifs de sécurité, une sécurité physique des ordinateurs, une protection antivirus et des solutions de blocage du courrier indésirable.
• Routage des messages   Utilisez le matériel réseau de tolérance de pannes et configurez correctement vos connecteurs et vos groupes de routage.
• Utilisation de plusieurs sites physiques   Protégez vos données contre les défaillances de site. Pour ce faire, effectuez une mise en miroir des données sur un ou plusieurs sites distants, ou implémentez des clusters dispersés sur le plan géographique pour autoriser le basculement en cas de défaillance d'un site.
• Procédures opérationnelles   Mettez à jour et analysez vos serveurs, utilisez des procédures standard et testez vos procédures de récupération d'urgence.
• Tests expérimentaux et déploiements pilotes   Avant de déployer votre système de messagerie dans un environnement de production, testez les performances et l'évolutivité dans des environnements de test et pilotes.

Protection de l'environnement physique des serveurs

Pour assurer la disponibilité de vos serveurs, vous devez adopter des normes strictes pour l'environnement dans lequel les serveurs doivent être exécutés. Pour accroître la longévité et la fiabilité de votre matériel serveur, prenez connaissance des informations suivantes :

• Température et humidité   Installez les serveurs importants dans une salle dédiée aux serveurs, à savoir, une salle qui permet un contrôle précis de la température et de l'humidité. Pour les ordinateurs, la température idéale est d'environ 21 degrés Celsius. En principe, la température n'est pas un problème dans un environnement de bureau. Cependant, pensez aux éventuelles conséquences d'un long week‑end d'été lorsque l'air conditionné ne fonctionne pas.
• Poussière ou particules   Dans la mesure du possible, protégez les serveurs et les autres équipements de la poussière et des particules, et vérifiez régulièrement qu'il n'y a pas de poussière. La poussière et les particules peuvent entraîner un court‑circuit ou une surchauffe des composants, ce qui peut provoquer des défaillances temporaires. Chaque fois que le capot d'un serveur est ouvert, vérifiez si l'unité a besoin d'être nettoyée. Auquel cas, vérifiez toutes les unités situées dans cette zone.
• Alimentation électrique   Tout comme pour la planification d'une récupération d'urgence, il est important d'anticiper les coupures d'électricité : cette opération implique l'identification des ressources indispensables au bon déroulement de votre activité. Dans la mesure du possible, l'alimentation de la salle d'ordinateurs doit provenir de deux circuits, et vous devez répartir les blocs d'alimentation redondants entre les sources d'alimentation. L'idéal serait de disposer de deux sources d'alimentation externes au bâtiment pour alimenter les circuits. Veillez à prendre en compte la puissance maximale susceptible d'être fournie sur un site. En raison d'un nombre trop élevé de serveurs sur un site, la puissance peut ne pas être suffisante pour permettre l'ajout d'un serveur supplémentaire. Envisagez une alimentation de secours au cas où une panne d'électricité surviendrait dans votre centre informatique. Il peut être nécessaire de continuer à faire fonctionner les ordinateurs dans d'autres bâtiments de votre zone ou dans d'autres zones loin de votre centre informatique. Vous pouvez utiliser des onduleurs pour gérer les coupures d'électricité brèves, et des générateurs de secours pour gérer les coupures d'électricité plus longues. Lorsque vous passez en revue les appareils qui nécessitent une alimentation de secours durant une coupure d'électricité, incluez les équipements réseau, tels que les routeurs.
• Maintenance des câbles   Pour éviter tout endommagement physique des câbles, assurez‑vous qu'ils sont en bon état et correctement disposés : adoptez soit un système de gestion des câbles, soit des attaches à tête d'équerre. Les câbles ne doivent en aucun cas être détachés dans un boîtier, car ils pourraient être déconnectés par inadvertance. Si vous en avez la possibilité, vérifiez les points de connexion de tous les câbles pour vous assurer que ces derniers sont correctement connectés. Par ailleurs, vérifiez que les câbles des équipements extractibles montés en rack disposent de suffisamment d'espace, et qu'ils ne sont pas pliés, tordus ou abîmés. Définissez les chemins d'accès corrects pour les jeux de câbles redondants. Si vous utilisez plusieurs sources d'alimentation ou communications réseau, efforcez‑vous d'acheminer les câbles vers les boîtiers électriques à partir de différents points. De cette manière, si un câble est abîmé, l'autre peut continuer à fonctionner. Ne branchez pas deux blocs d'alimentation sur la même prise de courant. Utilisez de préférence des onduleurs ou des sources d'alimentation distinctes (si possible connectées à des circuits différents) pour éviter un point de défaillance unique.

Mesures de sécurité

La sécurité joue un rôle crucial dans l'obtention d'un système de messagerie à disponibilité élevée. Bien que de nombreuses mesures de sécurité doivent être prises en compte, les mesures suivantes sont les plus importantes :

• Procédures d'autorisations
• Correctifs de sécurité
• Sécurité physique
• Protection antivirus
• Solutions de blocage du courrier indésirable

Pour obtenir des informations détaillées sur ces mesures et d'autres mesures de sécurité, voir le Guide sur le renforcement de la sécurité d'Exchange Server 2003.

Considérations du routage des messages

Votre topologie de routage constitue la base de votre système de messagerie. Par conséquent, lorsque vous planifiez cette topologie, vous devez prendre en considération les aspects liés au réseau, à la bande passante et à la géographie.

Le routage décrit la manière dont Exchange transfère les messages d'un utilisateur vers un autre. Lors de la planification de votre topologie de routage, vous devez comprendre le mode de transfert des messages au sein d'Exchange et établir une topologie permettant l'optimisation de ce transfert. Vous devez également déterminer les emplacements des connecteurs destinés à des systèmes de messagerie extérieurs à votre organisation Exchange. Une planification judicieuse peut réduire le volume du trafic réseau et optimiser les services Exchange et Windows.

Pour garantir la disponibilité et la fiabilité du routage de vos messages, prenez en compte les recommandations d'ordre général ci‑après :

• Assurez-vous que votre réseau physique intègre la redondance. Pour plus d'informations, voir « Matériel réseau » plus haut dans cette rubrique.
• Vérifiez que vous avez correctement configuré les connecteurs et les groupes de routage. Par exemple, dans certains scénarios, l'utilisation du Gestionnaire système Exchange pour configurer les chemins de connecteurs redondants permet d'éviter un point de défaillance unique.
• Configurez vos connecteurs de sorte qu'il existe plusieurs chemins d'accès vers chaque serveur tête de pont.
• Le cas échéant, vérifiez que vos serveurs passerelles SMTP (Simple Mail Transfer Protocol) sont redondants. Dans les grands centres de données, il est généralement recommandé de dédier des serveurs Exchange 2003 spécifiques au traitement exclusif du trafic SMTP entrant et sortant. Ces serveurs sont souvent appelés serveurs passerelles SMTP ou concentrateurs SMTP. Ils sont chargés d'acheminer le courrier SMTP entre les clients et les serveurs de boîtes aux lettres Exchange 2003 (serveurs principaux).

Pour plus d'informations sur la planification de la conception et de la configuration de votre routage (notamment des recommandations pour créer des connecteurs et des groupes de routage), voir la rubrique sur la Planification d'un système de messagerie Microsoft Exchange Server 2003.

Pour plus d'informations sur la procédure de configuration du routage des messages, voir le Guide de transport et de routage Exchange Server 2003.

Utilisation de plusieurs sites physiques

Pour améliorer la récupération d'urgence et accroître la disponibilité, certaines organisations utilisent plusieurs sites physiques. La plupart des configurations comprenant plusieurs sites incluent un site principal et un ou plusieurs sites distants qui sont le miroir du site principal. Le niveau de mise en miroir des composants et des données entre les sites dépend de l'accord sur le niveau de service et des besoins de l'entreprise. Une autre option consiste à mettre en place des clusters dispersés sur le plan géographique. Grâce à cette dispersion géographique, dans le cas d'une récupération d'urgence, les applications d'un site peuvent basculer vers un autre site.

Les sections suivantes fournissent des informations complémentaires sur la mise en miroir de sites et les clusters dispersés sur le plan géographique.

Mise en miroir de sites

La mise en miroir de sites implique une réplication synchrone ou asynchrone afin de mettre les données en miroir (par exemple, les données des journaux de transactions et les bases de données Exchange 2003) du site principal vers un ou plusieurs sites distants.

Si une défaillance d'un site complet survient au niveau du site principal, la durée nécessaire à la mise en ligne des services Exchange au niveau du site en miroir dépend de la complexité de votre organisation Exchange, de la quantité de matériel de secours préconfiguré dont vous disposez et du niveau d'assistance administrative dont vous bénéficiez. Par exemple, une organisation peut être en mesure de suivre une série de procédures de récupération d'urgence préplanifiées et d'effectuer la mise en ligne de son système de messagerie Exchange en 24 heures. Bien qu'une journée complète puisse être considérée comme une période d'immobilisation longue, vous pourrez peut‑être récupérer vos données pratiquement au point de défaillance. Pour plus d'informations sur la réplication synchrone et asynchrone des données Exchange, voir la section sur les technologies de réplication des données Exchange dans la rubrique Vue d'ensemble des technologies de stockage.

Clusters dispersés sur le plan géographique

Pour assurer la tolérance de pannes au niveau du site, il existe une méthode plus sophistiquée qui consiste à mettre en place des clusters dispersés sur le plan géographique. Pour déployer des clusters dispersés sur le plan géographique avec Windows Server 2003, vous devez utiliser des réseaux locaux virtuels pour connecter des réseaux SAN sur de longues distances.

Les configurations de clusters dispersés sur le plan géographique peuvent être complexes, et les serveurs en clusters doivent utiliser exclusivement des composants pris en charge par Microsoft. Vous devez déployer des clusters dispersés sur le plan géographique uniquement avec des fournisseurs qui offrent des configurations approuvées.

Pour plus d'informations sur les solutions de clusters dispersés sur le plan géographique avec Exchange 2003, voir la rubrique sur la Planification des clusters Exchange.

Pour plus d'informations sur Windows Server 2003 et les clusters dispersés sur le plan géographique, voir la rubrique sur les Clusters dispersés sur le plan géographique dans Windows Server 2003.

Méthodes opérationnelles conseillées

Lors de l'utilisation et de l'administration de votre système de messagerie Exchange 2003, il est important que votre personnel informatique adopte les méthodes conseillées IP standard. Cette section décrit les méthodes conseillées qui permettent d'optimiser la disponibilité de vos applications et de vos ordinateurs (ces informations s'appliquent aux environnements avec clusters et aux environnements sans clusters).

• Minimiser ou supprimer la prise en charge de plusieurs versions de systèmes d'exploitation, Service Packs et d'applications obsolètes
  Il est difficile d'offrir une prise en charge fiable lorsque plusieurs combinaisons de différentes versions de logiciels ou de matériel sont associées sur un système (ou sur des systèmes qui interagissent sur le réseau). Les logiciels, protocoles et pilotes obsolètes (et le matériel associé) ne sont d'aucune utilité lorsqu'ils ne prennent pas en charge les nouvelles technologies. Dédiez des ressources et du temps à la planification, au test et à l'installation de nouveaux systèmes d'exploitation, de nouveau matériel et de nouvelles applications. Lorsque vous prévoyez des mises à niveau logicielles, travaillez avec les utilisateurs pour identifier les fonctionnalités dont ils ont besoin. Offrez des formations pour assister les utilisateurs durant les transitions logicielles. Apportez des fonds à votre budget dédié au support et aux logiciels pour les futures mises à niveau des applications et des systèmes d'exploitation.

• Isoler les applications peu fiables
  Une application peu fiable est une application qui est indispensable à votre activité, mais qui ne répond pas aux normes appropriées en termes de fiabilité. Si vous devez travailler avec une application de ce type, vous avez le choix entre deux approches :

  • Retirez les applications peu fiables des serveurs qui sont les plus importants pour votre entreprise. Si vous savez qu'une application n'est pas fiable, prenez les mesures nécessaires pour l'isoler et ne l'exécutez pas sur un serveur stratégique.
  • Assurez un contrôle suffisant et utilisez les options de redémarrage automatique lorsque cela est utile. Un contrôle adapté implique d'effectuer des captures des mesures importantes des performances du système à intervalles réguliers. Pour configurer le redémarrage automatique d'une application ou d'un service, utilisez le composant logiciel enfichable Services. Pour plus d'informations sur les services Windows, voir « Vue d'ensemble des services » dans l'aide de Windows Server 2003.

• Utiliser du matériel actuel standard
  Tout matériel incompatible peut causer des problèmes de performances et des pertes de données. Mettez à jour votre matériel et adoptez une norme matérielle pour les nouveaux systèmes et les pièces de rechange.

• Prévoir les besoins futurs en termes de capacité
  La planification de la capacité est un facteur clé pour le succès des systèmes à disponibilité élevée. Pour connaître la capacité supplémentaire actuelle du système, étudiez et analysez votre système durant les périodes de charge maximale.

• Conserver une liste mise à jour des procédures opérationnelles
  Lorsqu'un problème système grave est résolu, veillez à supprimer les procédures obsolètes des plannings liés au support et à l'exploitation. Par exemple, lorsqu'un logiciel et remplacé ou mis à niveau, certaines procédures deviennent inutiles ou ne sont plus valides. Portez une attention toute particulière aux procédures qui font désormais partie de la routine. Assurez‑vous que toutes les procédures sont nécessaires et qu'elles ne constituent pas des solutions temporaires à des problèmes dont l'origine n'a pas été découverte.

• Adopter des méthodes d'analyse adaptées
  Si vous n'analysez pas correctement votre système de messagerie, vous ne parviendrez peut‑être pas à identifier les problèmes avant qu'ils ne deviennent critiques et ne causent des défaillances système. En l'absence d'analyse, la seule notification de l'existence d'un problème sera la défaillance d'une application ou d'un serveur.

• Déterminer la nature du problème avant d'intervenir
  Si le personnel d'exploitation n'est pas formé et n'a pas pour instruction d'analyser attentivement les problèmes avant de prendre des mesures, votre personnel peut consacrer beaucoup trop de temps à résoudre un problème de manière inadaptée. Qui plus est, il est possible qu'il n'utilise pas efficacement les outils d'analyse lorsque cela s'avère crucial, c'est‑à‑dire lorsque les premiers signes avant‑coureurs d'un problème apparaissent, et avant la défaillance effective.

• Traiter l'origine même des problèmes et non les symptômes
  Lors d'une défaillance inattendue ou lors d'une maintenance préventive temporaire, le traitement des symptômes constitue une stratégie efficace pour restaurer les services. Cependant, les traitements de symptômes qui sont ajoutés aux procédures d'exploitation standard peuvent se révéler impossibles à gérer. Les équipes du support peuvent être « saturées » par les traitements de symptômes, et il est possible qu'elles ne parviennent pas à réagir correctement lorsque de nouvelles défaillances surviennent.

• Éviter d'arrêter et de redémarrer les services et les serveurs pour mettre un terme aux erreurs
  L'arrêt et le redémarrage d'un serveur peuvent parfois se révéler nécessaires. Toutefois, si cette procédure corrige temporairement un problème mais ne le résout pas véritablement, elle peut alors entraîner d'autres problèmes.

Tests en laboratoire et déploiements pilotes

Avant de déployer une nouvelle solution, qu'il s'agisse d'une solution de tolérance de pannes ou de matériel réseau, d'outil de contrôle logiciel ou de clustering Windows, vous devez tester la solution de manière approfondie avant de la déployer dans un environnement de production. Une fois que vous avez testé la solution dans un laboratoire isolé, testez‑la dans le contexte d'un déploiement pilote où seuls quelques utilisateurs sont affectés, puis apportez les modifications nécessaires à la conception. Lorsque vous estimez que le déploiement pilote convient, effectuez un déploiement à grande échelle dans votre environnement de production.

Si votre organisation Exchange comprend un grand nombre d'utilisateurs, vous pouvez effectuer votre déploiement à grande échelle en plusieurs étapes. Après chaque étape, vérifiez que votre système peut gérer la charge accrue que représentent les utilisateurs supplémentaires avant de déployer le groupe d'utilisateurs suivant. Pour obtenir des informations complètes sur la configuration des environnements de test et pilotes, voir les rubriques sur la conception d'un environnement de test et d'un projet pilote dans le Kit de déploiement de Microsoft Windows Server 2003.

Outils de planification de la capacité Exchange

Déterminez le nombre de serveurs Exchange dont vous avez besoin pour gérer la charge des utilisateurs à l'aide des outils de planification suivants :

• Exchange Server Load Simulator 2003 (LoadSim)
• Outil ESP (Exchange Server Stress and Performance)
• Jetstress

Important :
Certains de ces outils créent des comptes dont les mots de passe ne sont pas sécurisés. Ils sont donc destinés uniquement à des environnements de test et non à des environnements de production.

Exchange Server Load Simulator 2003

L'outil LoadSim (Exchange Server Load Simulator) permet de simuler la charge des clients MAPI sur Exchange. L'exécution de tests LoadSim sur les ordinateurs clients permet de simuler la charge. Ces tests adressent des demandes de messagerie au serveur Exchange, générant ainsi une charge sur le serveur.

Vous pouvez utiliser les résultats de ces tests pour :

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

Vous pouvez télécharger LoadSim 2003 à partir du site Web de Téléchagements pour Exchange Server 2003.

Outil ESP (Exchange Server Stress and Performance)

L'outil ESP (Exchange Server Stress and Performance) 2003 est un outil d'évaluation du stress et des performances extrêmement évolutif pour Exchange. Il simule un grand nombre de sessions clients en accédant simultanément à un ou plusieurs services de protocoles. Des scripts contrôlent les actions exécutées par chaque utilisateur simulé. Ils renferment la logique permettant de communiquer avec le serveur. Ces scripts sont alors exécutés par des modules de tests (DLL). Ces derniers se connectent à un serveur via des protocoles Internet, des appels vers des interfaces de programmation d'applications (API) ou des interfaces telles qu'OLE DB.

ESP est un outil modulaire et extensible. Pour l'heure, il offre des modules pour la plupart des protocoles Internet, notamment :

• WebDAV
• IMAP4 (Internet Message Access Protocol version 4rev1)
• Protocole LDAP (Lightweight Directory Access Protocol)
• OLE DB
• POP3 (Post Office Protocol version 3)
• Protocole SMTP (Simple Mail Transfer Protocol)

Vous pouvez télécharger l'outil ESP 2003 (en anglais) à l'adresse https://go.microsoft.com/fwlink/?linkid=27881.

Jetstress

Exchange 2003 est une application qui nécessite une grande quantité d'espace disque. Pour pouvoir fonctionner correctement, Exchange doit s'appuyer sur un sous‑système de disques rapide et fiable. Jetstress (Jetstress.exe) est un outil Exchange qui permet aux administrateurs de vérifier les performances et la stabilité du sous‑système de disques avant de déployer les serveurs Exchange dans un environnement de production. Pour plus d'informations sur Jetstress et le stockage principal Exchange, voir la rubrique sur la Planification d'une solution de stockage principale fiable.

Vous pouvez télécharger l'outil Jetstress à l'adresse https://go.microsoft.com/fwlink/?linkid=27883.