Méthodes conseillées pour la configuration du stockage principal Exchange

 

Dernière rubrique modifiée : 2006-05-09

Il existe plusieurs consignes à respecter pour optimiser la disponibilité des données Exchange sur les serveurs principaux :

  • Configuration des groupes de stockage   Planifiez la configuration de vos groupes de stockage et de vos bases de données pour optimiser les performances et la récupération.
  • Quantité à stocker sur les serveurs de boîtes aux lettres   Planifiez la taille de vos bases de données pour garantir des performances et une récupération appropriées.
  • Partitionnement des serveurs principaux   Stockez les fichiers de votre système d'exploitation Windows, les fichiers d'application Exchange, les fichiers de base de données Exchange et les fichiers journaux des transactions sur des disques différents pour accroître la tolérance de pannes et optimiser la récupération.
  • Stockage des données Exchange   Mettez en place des solutions RAID sur vos disques pour faire correspondre le type de données sur chaque disque.
  • Espace sur le disque dur   Vérifiez que l'espace disque est suffisant pour garantir des performances et une récupération adaptées.
  • Performances des disques et débit E/S   Prenez en compte les performances des disques dans le cadre de votre solution de stockage.
  • Défragmentation des disques   Défragmentez vos disques à l'aide de la défragmentation en ligne, et au besoin, de la défragmentation hors connexion.
  • Optimisation de la mémoire virtuelle   Pensez à régler les paramètres de votre serveur pour garantir un transfert efficace et fiable des messages.

Il existe d'autres méthodes pour optimiser la disponibilité et les performances de vos serveurs principaux Exchange 2003. Pour plus d'informations sur le réglage des serveurs principaux Exchange 2003, voir le Guide des performances et de l'évolutivité d'Exchange Server 2003.

Configuration des groupes de stockage

La banque d'informations Exchange utilise deux types de bases de données : les banques de boîtes aux lettres et les banques de dossiers publics. Ces banques sont organisées en groupes de stockage. Toutes les bases de données dans un groupe de stockage partagent un ensemble unique de fichiers journaux des transactions, une planification unique de la sauvegarde et un ensemble unique de paramètres d'ouverture de session et de sauvegarde.

Votre stratégie de récupération d'urgence joue un rôle important dans la détermination du nombre de groupes de stockage et de bases de données pris en charge par votre solution de stockage. Votre plan de récupération doit en particulier spécifier les impératifs de délai de restauration de votre entreprise. C'est cet impératif qui dictera la configuration de stockage à retenir. La méthode de configuration que vous utilisez pour vos groupes de stockage dépend de l'édition de Microsoft Exchange 2003 que vous utilisez :

  • Si vous utilisez Exchange Server 2003 Standard Edition, chaque serveur Exchange peut avoir un groupe de stockage contenant une banque de boîtes aux lettres et une banque de dossiers publics.
  • Si vous utilisez Exchange Server 2003 Enterprise Edition, chaque serveur peut inclure jusqu'à quatre groupes de stockage, contenant chacun jusqu'à cinq bases de données (banques de boîtes aux lettres ou banques de dossiers publics).
noteRemarque :
Pensez à utiliser des noms descriptifs pour vos groupes de stockage, vos banques de boîtes aux lettres et vos banques de dossiers publics. Les noms descriptifs peuvent se révéler utiles pour les opérations de maintenance et de résolution des problèmes.

Avec Microsoft Exchange Server 2003 Standard Edition ou Exchange Server 2003 Enterprise Edition, vous pouvez créer un groupe de stockage de récupération en plus des autres groupes de stockage. Les groupes de stockage de récupération permettent de récupérer les données des boîtes aux lettres lors de la restauration de données provenant d'une sauvegarde. Pour plus d'informations sur les groupes de stockage de récupération, voir la rubrique sur l'utilisation des groupes de stockage de récupération d'Exchange Server 2003.

Stockage de boîtes aux lettres

Si vous utilisez Exchange Server 2003 Enterprise Edition, vous pouvez opter pour plusieurs banques de boîtes aux lettres afin d'accroître la fiabilité et d'améliorer la capacité de récupération de votre organisation Exchange. Si les utilisateurs sont répartis entre plusieurs banques de boîtes aux lettres, la perte d'une banque a une incidence sur un sous‑ensemble d'utilisateurs, et non sur l'ensemble de l'organisation. Par ailleurs, la réduction du nombre de boîtes aux lettres par banque réduit la durée de récupération d'une banque endommagée à partir d'une sauvegarde.

noteRemarque :
En général, lorsque vous répartissez vos utilisateurs sur plusieurs bases de données, votre système utilise plus de ressources que si vous deviez placer tous les utilisateurs sur une seule base de données. Cependant, étant donnée la réduction potentielle de la durée de récupération d'une banque de boîtes aux lettres, les avantages liés à l'utilisation de plusieurs banques l'emportent généralement sur les coûts en termes de ressources. Pour plus d'informations sur les performances des disques, voir la section sur les performances des disques et le débit E/S plus loin dans cette section.

Stockage de dossiers publics

Pour répartir des dossiers publics sur plusieurs serveurs, vous pouvez utiliser plusieurs banques de dossiers publics. De plus, vous pouvez placer plusieurs réplicas du même dossier sur plusieurs serveurs, afin d'accroître la capacité de votre système à gérer le trafic des utilisateurs. Si vous utilisez plusieurs groupes de routage, vous pouvez répartir les dossiers dans les groupes de routage. Ainsi, les utilisateurs peuvent facilement accéder aux dossiers qu'ils utilisent le plus souvent.

Quantité à stocker sur les serveurs de boîtes aux lettres

Avant de sélectionner les options pour la conception des services de vos serveurs de boîtes aux lettres, vous devez déterminer la quantité de données que vous devez stocker. La détermination précise du volume existant et anticipé de vos données de messagerie vous permet de concevoir correctement vos systèmes de stockage afin qu'il ne soit pas nécessaire d'étendre vos systèmes de stockage immédiatement après le déploiement.

Utilisez la formule suivante pour calculer la quantité de données susceptible d'être stockée sur un serveur :

(Nombre de boîtes aux lettres × limite de taille maximale des boîtes aux lettres) × facteur d'ajustement

Le facteur d'ajustement (par exemple, une valeur telle que 1,5) offre un espace supplémentaire pour les données qui ne sont pas comptées dans les quotas de boîte aux lettres, notamment les messages qui figurent dans la banque de rétention des éléments supprimés et la banque de rétention des boîtes aux lettres supprimées. Grâce aux quotas, les modèles d'utilisation de l'espace sont beaucoup plus prévisibles. Dans les environnements Exchange où les quotas de boîte aux lettres ne sont pas utilisés, l'activation des quotas est un point important à prendre en compte. Par ailleurs, la création de bases de données de boîte aux lettres distinctes et l'utilisation de plusieurs stratégies système avec différentes limites de quotas simplifie les tâches administratives.

noteRemarque :
Pour les utilisateurs qui ont besoin de boîtes aux lettres de grande capacité, il est possible de configurer une ou plusieurs bases de données sans aucune limite.

Vous pouvez utiliser le volume total des données pour parvenir à une estimation de la quantité d'espace disque nécessaire pour le serveur. Toutefois, le calcul de cette estimation dépend du nombre de bases de données de boîte aux lettres qui seront hébergées sur le serveur.

Considérations relatives aux performances des sauvegardes et des restaurations

Dans Exchange 2003 Enterprise Edition, aucune limitation n'est définie quant à la taille d'une base de données. Compte tenu qu'il n'existe aucune limite prédéfinie, il est difficile de déterminer la taille des serveurs et de savoir comment répartir les données entre les bases de données. Par conséquent, pour déterminer la quantité et la répartition des données sur les serveurs, tenez compte des facteurs suivants :

  • Quels sont vos impératifs en termes de délai pour la restauration d'une base de données ?
  • Le dispositif de restauration que vous avez sélectionné est‑il rapide ?

Pour illustrer ce processus, observons le scénario suivant :

Un contrat de niveau de service qui autorise une durée de panne maximale de quatre heures est associé à un système de sauvegarde susceptible de sauvegarder et de restaurer 75 Go de données par heure. Dans la mesure où une récupération est en moyenne deux fois plus longue qu'une sauvegarde, la quantité maximale pour l'ensemble des données d'un serveur sera de 150 Go (les 150 Go représentent la quantité de données qu'il sera possible de restaurer durant les deux heures).

Après avoir choisi la quantité maximale, vous devez déterminer comment partitionner les 150 Go en plus petits blocs. Dans la mesure où tous les utilisateurs du serveur sont dans une base de données, le placement de toutes les données dans une base de données unique n'offre aucune flexibilité. Il ne s'agit pas déterminer s'il faut opter pour le partitionnement ou non, mais de déterminer le nombre de partitions à utiliser. La solution courante consiste à prendre la quantité maximale de données sur le serveur, puis à la diviser de manière égale dans les bases de données. Par exemple, vous pouvez subdiviser une base de données de 150 Go dans cinq bases de données de 30 Go (cinq étant le nombre maximal de bases de données qu'il est possible d'intégrer dans un groupe de stockage). Malheureusement, cette solution n'autorise pas la sauvegarde et la restauration simultanées de plusieurs bases de données. Par ailleurs, il est également impossible de monter des bases de données supplémentaires à des fins de test ou de réparation. Une solution plus adaptée consisterait à utiliser plusieurs groupes de stockage (dans ce cas, deux groupes de stockage, chacun incluant quatre bases de données), chaque base de données devant utiliser environ 20 Go. Cette solution permettrait la sauvegarde ou la restauration simultanée deux bases de données issues de différents groupes de stockage (à condition que vous disposiez d'un matériel de sauvegarde adapté). De plus, étant donné que les fichiers de bases de données sont peu volumineux, vous pouvez déplacer facilement les fichiers entre les volumes ou les serveurs.

Considérations relatives au stockage d'instance simple

Il est également important de planifier la méthode de regroupement des boîtes aux lettres dans les bases de données de boîtes aux lettres. Étant donné que Microsoft Exchange peut assurer le stockage d'instance simple au sein des différentes bases de données, les utilisateurs des groupes de travail restent dans la même base de données lorsque cela est possible. Le stockage d'instance simple vous permet de restaurer certains groupes d'utilisateurs plus rapidement. Prenons l'exemple d'une banque pour laquelle les opérations de change requièrent une disponibilité plus élevée que les autres opérations. Si l'on reprend l'exemple précédent du serveur de 150 Go, la création d'un groupe de stockage supplémentaire avec une base de données uniquement pour les boîtes aux lettres des spéculateurs boursiers permettrait des sauvegardes et des restaurations plus rapides. Pour les boîtes aux lettres critiques, une autre option consisterait à utiliser le service Cliché instantané de volume pour assurer des récupérations encore plus rapides. L'inconvénient du coût de la configuration matérielle du service Cliché instantané de volume est ainsi minimisé.

Méthodes conseillées pour le partitionnement des serveurs principaux

Pour optimiser la tolérance de pannes et faciliter la résolution des problèmes, il convient de partitionner vos disques afin que les fichiers suivants ne soient pas situés sur les mêmes disques :

  • Fichiers Windows Server 2003
  • Fichiers d'application Exchange
  • Fichiers de base de données Exchange
  • Fichiers journaux des transactions Exchange

En règle générale, le partitionnement de vos disques durs de cette manière peut améliorer les performances et limiter la quantité de données à récupérer. Le reste de cette section décrit les avantages qui découlent de l'emplacement de ces fichiers sur des disques distincts.

Avantages liés à l'utilisation de disques distincts pour les fichiers d'application Exchange et les fichiers Windows Server 2003

Lorsque vous placez vos fichiers d'application Exchange et vos fichiers Windows Server 2003 sur deux disques distincts, les avantages sont les suivants :

  • Amélioration des performances   Les avantages en termes de performances sont significatifs pour les serveurs Exchange 2003. Par exemple, le serveur peut lire les fichiers Windows ou les fichiers Exchange dans l'ordre qui convient sans déplacer la tête de lecture autant que si les applications étaient situées sur un seul disque.
  • Tolérance de pannes optimisée   Un point de défaillance unique n'est plus un problème. Par exemple, en cas de défaillance des disques sur lesquels Exchange 2003 est installé, Windows Server 2003 continue de fonctionner.

Avantages liés à l'utilisation de disques distincts pour les fichiers journaux des transactions et les fichiers de base de données

Dans Exchange, l'accès aux fichiers journaux des transactions est séquentiel, et l'accès aux bases de données est aléatoire. Conformément aux principes de stockage généraux, vous devez séparer les fichiers journaux des transactions (E/S séquentielles) des bases de données (E/S aléatoires) afin d'optimiser les performances d'E/S et renforcer la tolérance de pannes. Le stockage des fichiers à accès séquentiel à part permet de maintenir les têtes de lecture en place pour des E/S séquentielles ce qui réduit le temps de recherche des données. Vous devez notamment placer chaque ensemble de fichiers journaux des transactions sur une baie qui lui soit propre, distincte des groupes de stockage et des bases de données.

Par défaut, Exchange stocke les fichiers de base de données et les fichiers journaux des transactions dans le dossier suivant :

lecteur:\Program Files\Exchsrvr\MDBDATA

Ce dossier est situé dans la partition sur laquelle vous installez Exchange 2003.

6f50ff0d-101f-430d-b81f-156080d8c9c3

Lorsque vous placez vos fichiers journaux des transactions et vos fichiers de base de données Exchange sur deux disques distincts, les avantages sont les suivants :

  • Gestion simplifiée des données Exchange   Une lettre de lecteur distincte est affectée à chaque ensemble de fichiers. La représentation de chaque ensemble de fichiers à l'aide d'une lettre de lecteur qui lui est propre vous permet d'assurer le suivi des partitions à sauvegarder en fonction de votre méthode de récupération d'urgence.
  • Amélioration des performances   Vous améliorez de manière significative les performances E/S des disques durs.
  • Impact limité d'un incident   En fonction du type de défaillance, le fait de placer les bases de données et les groupes de stockage sur des disques distincts peut minimiser sensiblement les pertes de données. Par exemple, si vous conservez vos bases de données Exchange et vos fichiers journaux des transactions sur le même disque dur physique et que ce disque connaît une défaillance, vous ne pouvez récupérer que les données qui existaient lors de votre dernière sauvegarde. Pour plus d'informations, voir la section sur la prise en compte des emplacements de vos fichiers journaux des transactions et fichiers de base de données du guide des opérations de récupération d'urgence de Microsoft Exchange Server 2003.

Le tableau suivant et la figure suivante illustrent un schéma de partitionnement possible pour un serveur Exchange comportant six disques durs, y compris deux groupes de stockage, contenant chacun quatre bases de données. Étant donné que le nombre de disques durs et de groupes de stockage sur votre serveur Exchange peut différer du nombre indiqué dans cet exemple, vous devez adapter cette logique en fonction de la configuration de votre propre serveur. Dans le tableau suivant, notez que les lecteurs E, F, G et H peuvent pointer vers des périphériques de stockage externes.

Schéma de partitionnement de disques durs Exchange

Disque Configuration de lecteur

Disque fixe 1

Lecteur C (NTFS) : fichiers du système d'exploitation et fichier d'échange Windows.

Disque fixe 2

Lecteur D (NTFS) : fichiers Exchange et applications de serveurs supplémentaires (tels que les logiciels antivirus et kits de ressources techniques).

Disque fixe 3

Lecteur E (NTFS) : fichiers journaux des transactions du groupe de stockage 1.

Disque fixe 4

Lecteur F (NTFS) : fichiers de base de données du groupe de stockage 1.

Disque fixe 5

Lecteur G (NTFS) : fichiers journaux des transactions du groupe de stockage 2.

Disque fixe 6

Lecteur H (NTFS) : fichiers de base de données du groupe de stockage 2.

9a4c7179-3c83-48d1-a21c-63987ff4a603

Vous pouvez appliquer les consignes de partitionnement présentées dans cette section, que vous stockiez les fichiers de base de données Exchange sur un serveur ou sur une solution de stockage avancée telle qu'une solution SAN. De plus, intégrez des technologies telles la mise en miroir de disques (RAID‑1) et l'agrégation de disques par bandes avec parité (RAID‑5 ou RAID‑6, en fonction du type de données stockées).

Pour plus d'informations sur les fichiers journaux des transactions, les bases de données et les groupes de stockage Exchange 2003, voir la section sur la présentation de la technologie des bases de données Exchange 2003 du guide des opérations de récupération d'urgence de Microsoft Exchange Server 2003.

Stockage des données Exchange

Cette section fournit des informations qui vous permettent de configurer correctement l'emplacement et les niveaux RAID pour les types de données Exchange suivants :

  • Fichiers de base de données (.edb et .stm)
  • Fichiers journaux des transactions
  • Données du répertoire de file d'attente SMTP
  • Fichiers d'indexation de contenu

Fichiers de base de données

Une base de données Exchange se compose d'un fichier texte enrichi (.edb) et d'un fichier de contenu MIME (Multipurpose Internet Mail Extensions) (.stm).

Le fichier .edb stocke les éléments suivants :

  • Tous les messages MAPI
  • Les tableaux utilisés pour le processus Store.exe pour trouver tous les messages
  • Totaux de contrôle des fichiers .edb et .stm
  • Pointeurs vers les données du fichier .stm

Le fichier .stm contient des messages qui sont transmis vers leur contenu Internet natif. Étant donné que l'accès à ces fichiers est généralement aléatoire, ces fichiers peuvent être placés sur le même disque.

Par défaut, Exchange stocke les fichiers de base de données dans le dossier suivant :

lecteur:\Program Files\Exchsrvr\MDBDATA

Ce dossier est situé dans la partition sur laquelle vous installez Exchange 2003.

Considérations relatives aux fichiers de base de données

Lorsque vous planifiez votre solution de stockage pour ces fichiers, adoptez une solution qui garantit la fiabilité. RAID-0 n'est pas une solution recommandée. Après avoir pris en compte le facteur de fiabilité, vous devez choisir entre une solution qui permette une optimisation des performances (RAID-1) et une solution qui permette une optimisation de la capacité (RAID-5). Dans la mesure du possible, choisissez la solution RAID-1 (ou RAID-0+1) pour ces fichiers.

Vous pouvez stocker des dossiers publics sur une baie RAID-5 car les données des dossiers publics sont écrites une feule fois et lues plusieurs fois. RAID-5 permet une amélioration des performances de lecture.

Fichiers journaux des transactions

Les journaux des transactions constituent l'aspect le plus important d'un groupe de stockage. Même si vous n'utilisez que l'option par défaut Premier groupe de stockage, vous devez examiner la configuration de vos journaux des transactions afin d'être certain de pouvoir récupérer les données en cas d'endommagement des banques.

L'enregistrement standard des transactions Exchange entraîne l'écriture de chaque transaction de banque (comme la création ou la modification d'un message) d'un groupe de stockage dans un fichier journal, puis dans la banque d'informations Exchange. Toutes les banques à l'intérieur d'un groupe de stockage partagent un ensemble unique de journaux des transactions. Le processus de consignation garantit l'existence des enregistrements de transactions même si un magasin venait à être endommagé entre deux sauvegardes. Dans de nombreux cas, la récupération d'une banque endommagée signifie la restauration du magasin à partir d'une sauvegarde, la relecture des fichiers journaux sauvegardés, puis la relecture des fichiers journaux les plus récents afin de récupérer les transactions effectuées après la dernière sauvegarde.

En cas d'incident, si vous devez reconstruire un serveur, vous pouvez utiliser les fichiers journaux de transactions les plus récents pour récupérer vos bases de données. Si vous avez accès à la sauvegarde la plus récente et aux fichiers journaux de transactions remontant à la dernière sauvegarde, vous pouvez récupérer toutes vos données. En revanche, si vous perdez l'un des fichiers journaux des transactions, les données ne sont pas validées dans la base de données puisque la dernière sauvegarde est définitivement perdue.

noteRemarque :
Pour des informations détaillées sur le fonctionnement des journaux des transactions, voir la section sur la présentation de la technologie des bases de données Exchange 2003 du guide des opérations de récupération d'urgence de Microsoft Exchange Server 2003.

Par défaut, Exchange stocke les fichiers journaux des transactions dans le dossier suivant :

lecteur:\Program Files\Exchsrvr\MDBDATA

Ce dossier est situé dans la partition sur laquelle vous installez Exchange 2003.

Considérations relatives aux fichiers journaux des transactions

Lorsque vous planifiez l'emplacement de vos fichiers journaux des transactions, Exchange, prenez en compte les éléments suivants :

  • Vous pouvez améliorer sensiblement les performances et la tolérance de pannes d'un serveur Exchange en plaçant les fichiers journaux des transactions sur un lecteur séparé.
  • Chaque groupe de stockage possède son propre ensemble de fichiers journaux des transactions. Par conséquent, le nombre de lecteurs de votre serveur dédiés aux journaux des transactions doit normalement correspondre au nombre de groupes de stockage planifiés. Avec une solution SAN, vous pouvez sélectionner un produit pour partitionner facilement l'espace virtualisé en lecteurs virtuels distincts pour les groupes de stockage et les fichiers journaux de transactions.
  • En outre, étant donné que ces fichiers journaux de transactions sont indispensables au fonctionnement d'un serveur, vous devez protéger les lecteurs contre les pannes, en procédant dans l'idéal à une mise en miroir matérielle à l'aide d'une baie RAID. Une configuration RAID-0+1 (dans laquelle les données sont mises en miroir puis agrégées par bandes) est recommandée.
noteRemarque :
Répartissez les lecteurs de bases de données entre plusieurs canaux ou contrôleurs SCSI (Small Computer System Interface), mais configurez-les comme un lecteur logique unique afin de minimiser la saturation du bus SCSI.

L'exemple ci-dessous illustre une configuration possible des disques :

  • C:\ Système et démarrage (ensemble de miroirs)
  • D:\ Fichier d'échange
  • E:\ Journaux des transactions pour le groupe de stockage 1 (ensemble de miroirs)
  • F:\ Journaux des transactions pour le groupe de stockage 2 (ensemble de miroirs)
  • G:\ Fichiers de base de données pour les deux groupes de stockage (plusieurs lecteurs configurés comme un agrégat par bandes avec parité)
noteRemarque :
Les lecteurs suivants doivent toujours être formatés pour NTFS :
  • partition système ;
  • Partition sur laquelle sont stockés des binaires Exchange
  • partitions contenant des fichiers journaux de transactions ;
  • partitions contenant des fichiers de base de données ;
  • partitions contenant d'autres fichiers Exchange.

Répertoire de file d'attente SMTP

Le répertoire de files d'attente SMTP joue un rôle important dans le processus de mise en file d'attente des messages SMTP (Simple Mail Transfer Protocol). Ce répertoire stocke les messages SMTP jusqu'à ce qu'ils soient écrits dans une base de données (publique ou privée, selon le type de messages) ou transférés vers un autre serveur ou connecteur. Dans la mesure où la mise en file d'attente des messages SMTP implique de nombreuses opérations d'écriture, il est important de configurer votre système pour des performances optimales.

En général, les messages sont stockés dans la file d'attente SMTP pour une courte période. Cependant, dans certaines situations (particulièrement en cas d'échec des processus en aval), la file d'attente SMTP doit stocker un volume de données important. Par conséquent, votre solution de stockage pour la file d'attente SMTP doit viser l'optimisation des performances avant de s'attacher à la capacité et à la fiabilité.

Par défaut, Exchange stocke les messages SMTP dans le dossier suivant :

lecteur:\Program Files\Exchsrvr\Mailroot

Ce dossier est situé dans la partition sur laquelle vous installez Exchange 2003. Dans certains cas (par exemple lorsque vous configurez un serveur tête de pont), vous pouvez améliorer les performances du serveur Exchange 2003 si vous placez le dossier Mailroot sur un autre disque dur ou sur une autre partition.

Considérations relatives aux files d'attente SMTP

Lorsque vous planifiez l'emplacement de vos données de files d'attente SMTP, prenez en compte les éléments suivants :

  • Une baie RAID‑0 ne doit pas être considérée comme la meilleure solution de stockage pour les files d'attente SMTP. En règle générale, la solution RAID-0 n'est acceptable que si la perte de courrier est acceptable. RAID-1 est une bonne solution car elle permet de disposer d'un certain niveau de fiabilité tout en assurant un débit suffisant. Toutefois, si vous visez des performances et une fiabilité optimales, la solution RAID‑0+1 pour la file d'attente SMTP est intéressante, en dépit de l'investissement supplémentaire qu'elle implique.
  • Dans Exchange 2003, vous pouvez désormais utiliser le Gestionnaire système Exchange pour modifier l'emplacement du répertoire des files d'attente. Cette option est disponible sous l'onglet Message de l'objet de serveur virtuel SMTP, dans le Gestionnaire système Exchange.

Fichiers d'indexation de contenu

L'indexation de contenu entraîne une pagination excessive durant l'analyse des bases de données, ainsi que de très nombreuses opérations d'écriture dans le fichier d'indexation de contenu. Par conséquent, vous ne devez pas placer le fichier d'indexation de contenu sur le même disque que le fichier d'échange (bien qu'il s'agisse de l'emplacement par défaut). Le fichier d'indexation de contenu est un fichier à accès aléatoire : il peut donc être placé sur le même lecteur que les bases de données, à condition que le sous‑système de disques puisse gérer la charge.

Considérations relatives à l'espace disque

Veillez à ce que les disques durs de vos serveurs Exchange disposent d'un espace disque suffisant. Vous devez avoir assez d'espace sur le disque dur pour pouvoir restaurer à la fois les fichiers de base de données et les fichiers journaux.

Votre sauvegarde peut être trop volumineuse pour être restaurée sur son emplacement d'origine. Par exemple, une sauvegarde hebdomadaire normale, à laquelle s'ajoutent six jours de sauvegardes différentielles, nécessite plus d'espace disque lors de sa restauration que vous n'en disposez sur votre serveur. Le nombre de fichiers générés au cours d'une semaine détermine si la restauration nécessite plus d'espace disque que vous n'en avez sur le serveur. Par exemple, la génération de 2 000 fichiers journaux en une semaine équivaut à 10 Go d'espace disque, qui viennent s'ajouter à l'espace requis pour la base de données.

La réalisation de sauvegardes normales quotidiennes permet de réduire l'espace nécessaire à la restauration de vos bases de données Exchange. Cela tient au fait que les sauvegardes normales suppriment les fichiers journaux des transactions générés avant la sauvegarde. Si vous devez restaurer vos bases de données Exchange, effectuez des sauvegardes classiques tous les jours, de manière à ne pas avoir plus d'une journée de génération de fichiers journaux à restaurer.

En outre, le lecteur de base de données (le disque dur qui contient les fichiers .edb et .stm) ne doit jamais être occupé à plus de la moitié de sa capacité. Bien que l'occupation partielle d'un lecteur de base de données se traduise par de l'espace disque inutilisé, cela permet de réduire le temps d'indisponibilité du serveur pour les raisons suivantes :

  • Vous pouvez restaurer les bases de données plus rapidement qu'avec un lecteur saturé (surtout si le système de fichiers est fragmenté).
  • Vous pouvez effectuer une défragmentation hors connexion sur le même disque physique, au lieu de copier les bases de données sur un serveur de maintenance (opération beaucoup plus longue que la copie des fichiers de base de données dans un répertoire temporaire sur le même disque dur physique).
  • Vous pouvez sauvegarder une copie des bases de données sur le même disque physique avant de les restaurer, ce qui vous permet de réparer les bases de données en cas de problème au cours du processus de restauration (par exemple, si la sauvegarde existante contient des erreurs). Par conséquent, il est conseillé de déplacer ou copier la base de données en cours et les fichiers journaux avant de restaurer une base de données. Pour plus d'informations sur la restauration des bases de données Exchange, voir le guide des opérations de récupération d'urgence Microsoft Exchange Server 2003.
    noteRemarque :
    Étant donné la taille de la moyenne des bases de données, la copie de votre base de données la plus actualisée sur un disque physique différent ou sur un autre serveur peut ajouter plusieurs heures à la période d'indisponibilité. En revanche, si vous avez suffisamment d'espace disque local sur le même lecteur physique, vous pouvez déplacer les fichiers de la base de données en cours vers un autre dossier, à partir de l'invite de commandes ou de l'Explorateur Windows, avant de procéder à la restauration.

Performances des disques et débit E/S

Le débit E/S des disques nécessaire pour prendre en charge un nombre spécifique d'utilisateurs est tout aussi important qu'une quantité d'espace disque suffisante. Ceci est particulièrement important pour les applications qui nécessitent une grande quantité d'espace disque telles que Microsoft Exchange 2003. En général, ce sont la vitesse des disques et le nombre de disques physiques qui ont la plus grande incidence sur les performances de stockage globales. Si des disques de grande capacité ou des disques lents sont utilisés sur un réseau SAN pour fournir l'espace de stockage requis, les impératifs d'E/S des disques (et non l'espace de stockage) sont alors le facteur déterminant pour l'évaluation de la configuration du stockage. Dans de nombreux cas, un plus grand nombre de disques peut être nécessaire, non pas pour l'espace de stockage supplémentaire, mais pour les E/S plus importantes liées aux piles complémentaires.

Par exemple, imaginons un numéro d'unité logique correctement évalué et équilibré, qui est composé de dix lecteurs de disque de 18 GB fonctionnant à 15 000 TPM pour un groupe de bases de données incluant des quotas de boîtes aux lettres de 50 mégaoctets (Mo). Cinq lecteurs de disques de 36 Go à 15 000 TPM fourniraient la même quantité de stockage mais avec seulement la moitié des piles de disques et, par conséquent, seulement la moitié des opérations d'E/S par seconde (ce qui peut correspondre à des performances insuffisantes des E/S de disques). Il est également important de noter que le doublement de la taille du numéro d'unité logique en utilisant dix lecteurs de disques de 36 Go à 15 000 TPM ne signifie pas nécessairement que le quota de boîtes aux lettres peut passer de 50 à 100 Mo. Bien qu'une configuration de ce type puisse assurer des performances égales ou supérieures pour les E/S par seconde, le doublement potentiel de la taille des bases de données augmentera probablement la durée de récupération des bases de données par rapport à la durée stipulée dans le contrat de niveau de service.

D'après les évaluations de performances d'Exchange 2003 MAPI Messaging Benchmark version 3 (MMB3), chaque utilisateur génère, en moyenne, 0,5 demande d'E/S par seconde sur la base de données qui contient sa boîte aux lettres. Si l'on analyse les débits d'E/S des disques, il est possible d'évaluer le nombre de piles requis du point de vue des E/S.

noteRemarque :
Pour plus d'informations sur MMB3, voir la rubrique sur Exchange Server 2003 MAPI Messaging Benchmark 3 (MMB3).

Pour faciliter la compréhension de ce concept, le tableau suivant présente des exemples de débits d'E/S de disque par seconde.

Exemples de débits d'E/S de disque par seconde

Vitesse du disque E/S par seconde Utilisateurs MMB3 par disque

7 200 TPM

100

200

10 000 TPM

125

250

15 000 TPM

166

332

L'évaluation des E/S pour un disque fonctionnant à 7 200 TPM (répertorié dans le tableau 4.3) indique qu'une pile à 7 200 TPM fournit suffisamment d'E/S de disque pour 200 utilisateurs MMB3 simultanés. Un agrégat par bandes pour un groupe de stockage contenant 2 000 utilisateurs nécessiterait dix disques à 7 200 TPM. Dans une configuration RAID 0+1 (qui offre des capacités de récupération bien supérieures à une baie de disques agrégés), 20 disques sont nécessaires pour les bases de données du groupe de stockage avec 2 000 utilisateurs.

D'après les données du tableau 4.3, la prise en charge de 2 000 utilisateurs MMB3 (avec un quota individuel de boîte aux lettres de 50 Mo) dans un groupe de stockage utilisant des disques de 36 Go à 10 000 TPM nécessite huit disques dans un agrégat par bandes (ou 16 pour un agrégat RAID 0+1). Huit disques de 36 Go correspondent à un numéro d'unité de disque de 288 Go, quantité de stockage bien supérieure aux impératifs d'un numéro d'unité de disque de 110 Go. Dans ce cas, avec des disques de 360 Go à 10 000 TPM, les impératifs au niveau des E/S, et non la capacité de stockage, déterminent les choix en matière de configuration du stockage.

L'optimisation des E/S de disques sur le réseau SAN constitue l'une des principales opérations d'amélioration des performances que vous pouvez effectuer dans votre organisation Exchange. Pour cela, chaque fournisseur SAN utilise différentes options et impératifs. Par conséquent, lorsque vous concevez des implémentations de solutions SAN, vous devez garder à l'esprit vos impératifs de configuration quant aux E/S. Pour Exchange, ces impératifs sont les suivants :

  • Comme taille native des E/S, Exchange utilise des pages de 4 Ko, bien que de nombreuses transactions se traduisent parfois par des demandes d'écriture ou de lecture pour plusieurs pages.
  • Les numéros d'unité logique des journaux des transactions doivent être optimisés pour les opérations d'écriture séquentielle car l'accès aux journaux (que ce soit en lecture ou en écriture) est toujours séquentiel.
  • Les numéros d'unité logique des bases de données doivent être optimisés pour une quantité appropriée d'opérations de lecture et d'écriture aléatoire. Vous pouvez déterminer la quantité de manière expérimentale ; pour ce faire, utilisez les outils ESP (Exchange Stress and Performance) et Jetstress.
  • Les impératifs en termes de capacité de récupération et de contrat de niveau de service doivent être pris en compte.

Pour plus d'informations sur la procédure de planification de votre système de stockage pour optimiser les performances et la disponibilité, voir la rubrique sur l'accélérateur de solution pour MSA Enterprise Messaging.

Pour plus d'informations sur la planification de votre architecture de stockage, voir la section sur l'architecture de stockage MSA du kit d'architecture de référence MSA.

Défragmentation des disques

La défragmentation des disques consiste à réorganiser les données résidant sur les disques durs d'un serveur de manière à ce que les fichiers soient plus contigus, ce qui rend les lectures plus efficaces. La défragmentation des disques durs permet d'améliorer les performances des disques et de veiller à ce que vos serveurs Exchange fonctionnent sans heurts et de manière efficace.

Étant donné qu'une fragmentation accentuée des disques peut entraîner des problèmes de performances, exécutez régulièrement un programme de défragmentation de disques (Disk Defragmenter, par exemple) ou lorsque les performances des serveurs sont inférieures à la normale. Lorsque vous sauvegardez un système de fichiers fortement fragmentés, le nombre de lectures sur disque est plus élevé, c'est pourquoi vous devez veiller à ce que vos disques aient été récemment défragmentés.

Les bases de données Exchange nécessitent également une défragmentation. Cependant, la fragmentation des données Exchange intervient au sein même des bases de données Exchange. Plus précisément, la défragmentation des bases de données Exchange consiste à réorganiser les données des banques de boîtes aux lettres et des banques de dossiers publics pour remplir les pages des bases de données plus efficacement, ce qui permet d'éliminer l'espace de stockage non utilisé.

Il existe deux types de défragmentation des bases de données Exchange : la défragmentation en ligne et la défragmentation hors connexion.

Défragmentation en ligne

Par défaut, sur les serveurs Exchange 2003, la défragmentation en ligne a lieu tous les matins, entre 1h et 5h. La défragmentation en ligne détecte et supprime automatiquement les objets qui ne sont plus utilisés. Cette procédure permet de fournir un espace plus important pour les bases de données, sans pour autant modifier la taille des fichiers de bases de données qui font l'objet d'une défragmentation.

noteRemarque :
Pour optimiser l'efficacité des processus de défragmentation et de sauvegarde, ne planifiez pas vos procédures de maintenance et vos opérations de sauvegarde au même moment.

Ci-après figurent deux méthodes permettant de planifier la défragmentation des bases de données :

  • Pour planifier la défragmentation d'une seule base de données, utilisez l'option Fréquence d'exécution de la maintenance sous l'onglet Base de données d'un objet de banque de dossiers publics ou de banque de boîtes aux lettres.
  • Pour planifier la défragmentation d'un ensemble de banques de dossiers publics et de banques de boîtes aux lettres, utilisez l'option Fréquence d'exécution de la maintenance sous l'onglet Base de données (Stratégie) d'une stratégie de banque de dossiers publics ou de banque de boîtes aux lettres.

Pour plus d'informations sur la création d'une stratégie de banque de boîtes aux lettres ou de banque de dossiers publics, voir les rubriques sur la création d'une stratégie de banque de boîtes aux lettres et sur la création d'une stratégie de banque publique dans l'aide d'Exchange 2003.

Défragmentation hors connexion

La défragmentation hors connexion implique l'utilisation de l'outil Exchange Eseutil.exe (Server Database Utilities). Cet outil crée une nouvelle base de données, copie les anciens enregistrements de la base de données dans le nouvel enregistrement, puis supprime les pages inutilisées, ce qui permet d'obtenir un nouveau fichier de base de données compact. Pour réduire la taille des fichiers des bases de données, vous devez effectuer une défragmentation hors connexion dans les cas de figure suivants :

  • Après la réparation d'une base de données (à l'aide d'Eseutil /p)
  • Après avoir déplacé une quantité considérable de données à partir d'une base de données Exchange.
  • Lorsqu'une base de données Exchange est beaucoup plus volumineuse qu'elle ne devrait l'être.
noteRemarque :
N'envisagez une défragmentation hors connexion que si de nombreux utilisateurs sont déplacés du serveur Exchange 2003 ou après une réparation de base de données. Si vous effectuez une défragmentation hors connexion lorsque cela n'est pas nécessaire, les performances pourront s'en ressentir.

Lorsque vous utilisez l'outil Eseutil.exe pour défragmenter vos bases de données Exchange, prenez en compte les éléments suivants :

  • Pour reconstruire la nouvelle base de données défragmentée à un autre emplacement, exécutez Eseutil.exe en mode défragmentation (à l'aide de la commande Eseutil /d) et incluez le commutateur /p. L'utilisation du commutateur supplémentaire /p pendant une opération de défragmentation vous permet de conserver votre base de données défragmentée initiale (au cas où vous devriez rétablir cette base de données ultérieurement). Qui plus est, l'utilisation de ce commutateur réduit considérablement la durée de défragmentation d'une base de données.
  • Étant donné que la défragmentation hors connexion modifie totalement les pages d'une base de données, vous devez créer de nouvelles sauvegardes des bases de données Exchange 2003 immédiatement après la défragmentation hors connexion. Si vous recourez à l'utilitaire Sauvegarde pour effectuer la sauvegarde de vos bases de données Exchange, créez de nouvelles sauvegardes normales de vos bases de données Exchange. Si vous ne créez pas de nouvelles sauvegardes normales, les sauvegardes antérieures incrémentielles ou différentielles ne fonctionneront pas correctement car elles référencent les pages de base de données qui ont été réorganisées par la procédure de défragmentation.

Optimisation de l'utilisation de la mémoire

L'espace d'adresse virtuelle est un critère important à prendre en compte lors du déploiement d'un système de messagerie Exchange. Les performances globales et l'évolutivité d'un serveur de boîtes aux lettres sont déterminées par l'utilisation de l'espace d'adresse virtuelle du serveur. Lorsqu'il ne reste plus beaucoup de mémoire virtuelle, les performances diminuent considérablement. Bien que Microsoft Exchange 2003 optimise automatiquement l'utilisation de la mémoire pour les petits et moyens serveurs, un réglage supplémentaire est nécessaire pour les serveurs possédant plus d'un gigaoctet de mémoire physique.

Pour plus d'informations sur les conséquences de la fragmentation de la mémoire virtuelle et pour obtenir des instructions en vue d'optimiser l'utilisation de la mémoire, voir le guide des performances et de l'évolutivité d'Exchange Server 2003.

Autres problèmes de configuration liés à Windows et à Exchange

Lorsque vous planifiez un système de messagerie à disponibilité élevée, vous devez tenir compte de nombreuses recommandations en matière de configuration. Toutefois, ce guide n'a pas pour but de fournir une explication détaillée des ces recommandations en matière de configuration. Pour obtenir des informations exhaustives sur la configuration de votre système de messagerie pour offrir une disponibilité, une évolutivité et des performances élevées, voir le guide des performances et de l'évolutivité d'Exchange Server 2003.