Conception du stockage de serveur de boîtes aux lettres

 

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

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

Disposer de capacités suffisantes est essentiel. Lorsqu'un disque de base de données n'a plus d'espace disque, la base de données passe en mode hors connexion. Lorsqu'un disque de journal des transactions n'a plus d'espace disque, toutes les bases de données de ce groupe de stockage passent en mode hors connexion. L'octroi d'espace supplémentaire est souvent une opération difficile à effectuer rapidement et la réalisation d'un compactage en mode hors connexion pour récupérer de l'espace peut prendre du temps. Dans la plupart des cas, le manque d'espace disque provoque une interruption de la disponibilité d'une ou plusieurs bases de données pour une durée qui dépasse généralement la plupart des objectifs de temps de récupération (RTO).

Cette rubrique fournit des informations sur les points suivants :

• calculateur de stockage de boîtes aux lettres pour Exchange 2007 ;

• capacité de numéro d'unité logique de base de données ;

• capacité de numéro d'unité logique de journal ;

• E/S transactionnelles

• prévision des ESPS de ligne de base d'Exchange 2007 ;

• E/S non transactionnelles ;

• numéros d'unité logique (LUN) et disques physiques ;

• impact de la réplication continue sur la conception du stockage.

Calculateur de stockage de boîtes aux lettres pour Exchange 2007

Le calculateur des besoins en stockage du rôle serveur de boîtes aux lettres Exchange Server 2007 (calculateur de stockage) permet de déterminer les besoins en stockage (performances et capacité d'E/S), ainsi qu'une configuration de numéros d'unité logique optimale en fonction d'un ensemble de facteurs d'entrée. De nombreux facteurs d'entrée doivent être pris en compte avant de pouvoir concevoir une solution de stockage optimale pour un serveur de boîtes aux lettres Exchange 2007. Ces facteurs d'entrée sont décrits dans cette rubrique.

Le calculateur de stockage permet d'entrer des valeurs spécifiques à votre organisation et vous présente des recommandations relatives aux besoins en E/S et en capacité, ainsi que la configuration de numéros d'unité logique optimale.

Pour plus d'informations sur le calculateur de stockage, notamment sur son utilisation, consultez l'article du blog de l'équipe Exchange Calculateur des besoins en stockage du rôle serveur de boîtes aux lettres Exchange Server 2007, où vous pourrez également télécharger le calculateur.

Notes

UNRESOLVED_TOKEN_VAL(exBlog)

Capacité de numéro d'unité logique de base de données

Il existe plusieurs points de données permettant de déterminer la manière de dimensionner un numéro d'unité logique de base de données. En outre, d'autres facteurs sont également à prendre en compte. Une fois tous les facteurs pris en compte et calculés, il est recommandé d'inclure un facteur de traitement supplémentaire pour le numéro d'unité logique de base de données de 20 %. Cette valeur tient compte des autres données résidant dans la base de données qui ne sont pas nécessairement visibles lors du calcul des tailles de boîtes aux lettres et des espaces blancs. Par exemple, la structure des données (tables, affichages et index internes) au sein de la base de données augmente la taille globale de la base de données. Par exemple, si, après la lecture des sous-sections suivantes, vous déterminez que vous avez besoin de 120 Go, il est recommandé de prévoir 144 Go, en prenant une marge de sécurité de 20 % pour le numéro d'unité logique de base de données de ce groupe de stockage.

Quota de boîte aux lettres

La première mesure à comprendre est la taille de la boîte aux lettres. Le calcul du volume de données qu'un utilisateur final est autorisé à stocker dans sa boîte aux lettres permet de déterminer le nombre d'utilisateurs pouvant être hébergés sur le serveur. Même si les tailles et les quotas finaux des boîtes aux lettres changent, avoir un objectif constitue la première étape du calcul des besoins en capacité. Par exemple, si vous avez 5 000 utilisateurs sur un serveur disposant d'un quota de boîte aux lettres de 250 Mo, vous avez besoin d'au moins 1,25 To (téra-octets) d'espace disque. Si une limite stricte n'est pas définie sur des quotas de boîte aux lettres, il sera difficile d'évaluer les besoins en capacité.

Espaces blancs dans la base de données

La taille de la base de données sur le disque physique ne correspond pas simplement au nombre d'utilisateurs multiplié par le quota d'utilisateurs. Lorsque la plupart des utilisateurs n'avoisinent pas leur quota de boîte aux lettres, les bases de données consomment moins d'espace et les espaces blancs ne constituent pas un problème de capacité. La base de données elle-même comporte toujours des pages blanches ou des espaces blancs. Lors de la maintenance en ligne, les éléments marqués pour la suppression de la base de données sont supprimés et libèrent ces pages. Le pourcentage d'espaces blancs est en constante évolution ; il est à son plus haut niveau juste après la maintenance en ligne et au plus bas juste avant.

Il est possible d'évaluer la taille des espaces blancs d'une base de données sur la base de la quantité de messages échangés par les utilisateurs ayant des boîtes aux lettres dans celle-ci. Par exemple, si vous avez cent boîtes aux lettres de 2 Go (totalisant 200 Go) dans une base de données dont les utilisateurs échangent en moyenne 10 Mo de messages par jour, les espaces blancs totalisent environ 1 Go (100 boîtes aux lettres * 10 Mo par boîte aux lettres).

Les espaces blancs peuvent augmenter au-delà de cette approximation si la maintenance en ligne n'effectue pas un passage complet. Il est important que vos activités opérationnelles allouent une durée suffisante à la maintenance en ligne pour qu'elle s'effectue chaque nuit, de sorte qu'un passage complet soit accompli en une semaine ou moins.

Conteneur de dépôt de base de données

Chaque base de données dispose d'un conteneur de dépôt stockant les éléments ayant subi une suppression logicielle. Par défaut, les éléments sont stockés pendant 14 jours dans Microsoft Exchange Server 2007. Cela inclut les éléments ayant été supprimés du dossier Éléments supprimés. Par défaut, en comparaison avec Exchange Server 2003, Exchange 2007 augmente le traitement consommé par le conteneur de dépôt de base de données, car les éléments supprimés sont désormais stockés deux fois plus longtemps. La taille réelle du conteneur de dépôt dépend de la taille de chaque élément et des paramètres de rétention spécifiques à votre organisation.

Une fois la période de rétention terminée, ces éléments sont supprimés de la base de données lors d'un cycle de maintenance en ligne. Enfin, l'état stabilisé est atteint lorsque la taille de votre conteneur de dépôt équivaut au volume de courrier entrant/sortant pendant deux semaines, en termes de pourcentage de la taille de votre base de données. Le pourcentage exact dépend du volume de courrier supprimé et de la taille des boîtes aux lettres individuelles.

Le conteneur de dépôt ajoute un pourcentage de traitement à la base de données en fonction de la taille de la boîte aux lettres et du taux de remise de messages pour cette boîte aux lettres. Par exemple, avec un taux de remise de messages constant de 52 Mo par semaine, une boîte aux lettres au profil important de 250 Mo stocke environ 104 Mo dans le conteneur de dépôt, ajoutant 41 % de traitement. Une boîte aux lettres de 1 Go stockant les mêmes 104 Mo dans le conteneur de dépôt ajoute 10 % de traitement.

Taille réelle de la boîte aux lettres

Progressivement, les boîtes aux lettres d'utilisateur atteignent le quota de boîte aux lettres, si bien qu'un volume de courrier équivalent au courrier entrant doit être supprimé pour que le quota soit respecté. Cela signifie que le conteneur de dépôt augmente jusqu'à une taille maximale équivalent à deux semaines de courrier entrant/sortant. Si la plupart des utilisateurs n'atteignent pas le quota de boîte aux lettres, seule une partie du courrier entrant/sortant est supprimée, de sorte que la croissance est divisée entre le conteneur de dépôt et l'augmentation de la taille de base de données. Par exemple, une boîte aux lettres de profil de message de 250 Mo recevant 52 Mo de courrier par semaine (avec une taille moyenne de message de 50 kilo-octets (Ko)) utilise 104 Mo du conteneur de dépôt (41 %) et 7,3 Mo d'espaces blancs, pour une taille totale de boîte aux lettres de 360 Mo. Autre exemple, une boîte aux lettres de 2 Go recevant 52 Mo de courrier par semaine présente un profil de message très lourd, qui entraîne l'utilisation de 104 Mo du conteneur de dépôt (5 %) et 7,3 Mo d'espaces blancs, pour une taille totale de boîte aux lettres de 2,11 Go. Cinquante boîtes aux lettres de 2 Go dans un groupe de stockage totalisent 105,6 Go.

Ci-après, vous trouverez une formule correspondant à une taille de base de données utilisant une boîte aux lettres de 2 Go :

Taille de boîte aux lettres = Quota de boîte aux lettres + Espaces blancs + (Courrier hebdomadaire entrant × 2)

Taille de boîte aux lettres = 2,048 Mo + (7.3 Mo) + (52 Mo × 2)

2,159 Mo = 2,048 Mo + 7.3 Mo + 104 Mo (5 % de plus que le quota)

Après que vous avez déterminé la taille de boîte aux lettres réelle projetée, vous pouvez utiliser cette valeur pour déterminer le nombre maximal d'utilisateurs par base de données. Prenez la taille de la boîte aux lettres projetée et divisez-la par la taille maximale de base de données recommandée. Cela vous aide également à déterminer le nombre de bases de données dont vous avez besoin pour gérer le nombre d'utilisateurs projeté, en supposant que les bases de données sont entièrement remplies. Sachez qu'en raison d'entrées/sorties (E/S) non transactionnelles ou de limitations matérielles, il se peut que vous deviez modifier le nombre d'utilisateurs par serveur. Certains administrateurs préfèrent utiliser un plus grand nombre de bases de données afin d'en réduire la taille. Cette approche peut faciliter les choses au niveau des fenêtres de sauvegarde et de restauration, au prix d'une plus grande complexité résultant de la gestion d'un plus grand nombre de bases de données par serveur.

Indexation de contenu

L'indexation du contenu crée un index ou un catalogue permettant aux utilisateurs de rechercher rapidement et facilement au sein des éléments de courrier au lieu de rechercher manuellement dans la boîte aux lettres. Exchange 2007 crée un index correspondant à environ 5 pour cent de la taille totale de la base de données, qui est placé sur le même numéro d'unité logique que la base de données. Des besoins en capacités supplémentaires de 5 % doivent être pris en compte dans la taille du numéro d'unité logique de base de données pour l'indexation du contenu.

Maintenance

Une base de données devant être réparée ou compactée en mode hors connexion a besoin d'une capacité équivalente à la base de données cible plus 10 %. Si vous attribuez assez d'espace pour une seule base de données, un seul groupe de stockage ou un ensemble de sauvegardes, de l'espace supplémentaire doit être disponible pour réaliser ces opérations.

Groupe de stockage de récupération

Si vous prévoyez d'utiliser un groupe de stockage de récupération dans vos plans de récupération d'urgence, vous devez disposer d'une capacité suffisante pour traiter toutes les bases de données que vous voulez restaurer simultanément sur ce serveur.

Sauvegarde sur disque

De nombreux administrateurs réalisent des sauvegardes en ligne continues sur un disque cible. Si votre conception de sauvegarde et de restauration implique une sauvegarde sur disque, des besoins en capacité suffisants doivent être disponibles sur le serveur pour héberger la sauvegarde. En fonction du type de sauvegarde que vous utilisez, cette capacité peut être aussi petite que la base de données et les journaux ou aussi volumineuse que la base de données et tous les journaux créés depuis la dernière sauvegarde complète.

Capacité de numéro d'unité logique de journal

Les fichiers journaux de transactions sont un enregistrement de chaque transaction effectuée par le moteur de la base de données. Toutes les transactions sont d'abord écrites dans le journal, puis dans la base de données. Contrairement aux versions précédentes d'Exchange, la taille des fichiers journaux des transactions dans Exchange 2007 est passée de 5 Mo à 1 Mo. Cette modification a été apportée pour prendre en charge les fonctions de réplication en continu et réduire le volume de perte de données en cas de défaillance du stockage principal.

Le tableau suivant permet d'estimer le nombre de fichiers journaux des transactions qui seront générés sur un serveur de boîtes aux lettres Exchange 2007 pour lequel la taille moyenne des messages est de 50 Ko.

Nombre de fichiers journaux des transactions générés pour chaque profil de boîte aux lettres

Profil de boîte aux lettres	Profil de message	Fichiers journaux générés / boîte aux lettres
Light	5 envois/20 réceptions	6
Moyen	10 envois/40 réceptions	12
Très lourd	20 envois/80 réceptions	24
Très lourd	30 envois/120 réceptions	36
Extrêmement lourd	40 envois/160 réceptions	48

Les instructions suivantes ont été établies pour définir la manière dont la taille des messages a une incidence sur la fréquence de génération des fichiers journaux :

• Si la taille maximale des messages double pour atteindre 100 Ko, les fichiers journaux générés par boîte aux lettres augmentent d'un facteur de 1,9. Ce nombre représente le pourcentage de base de données contenant les tables de pièces jointes et de messages (corps des messages et pièces jointes).

• Par la suite, lorsque la taille des messages double pour devenir supérieure à 100 Ko, la vitesse de génération des fichiers journaux par boîte aux lettres double également.

Par exemple :

• Si le profil de boîte aux lettres est Lourd et la taille moyenne des messages est 100 Ko, le nombre de fichiers journaux générés par boîte aux lettres est le suivant : 24 × 1.9 = 46.

• Si le profil de boîte aux lettres est Lourd et la taille moyenne des messages est 200 Ko, le nombre de fichiers journaux générés par boîte aux lettres est le suivant : 24 × 3,8 = 91.

Considérations concernant la sauvegarde et la restauration

La plupart des entreprises effectuant une sauvegarde complète de nuit attribuent, en termes de capacité, l'équivalent de 3 jours de fichiers journaux dans un groupe de stockage sur le numéro d'unité logique de journal des transactions. Cela est effectué pour empêcher une défaillance dans la sauvegarde qui causerait le remplissage du lecteur du journal et donc le démontage du groupe de stockage.

Le dimensionnement du numéro d'unité logique de journal est en quelque sorte dépendant de votre conception de sauvegarde et de restauration. Par exemple, si votre conception vous permet de revenir deux semaines en arrière et de relire tous les journaux générés depuis lors, la valeur de deux semaines d'espace de fichier journal est nécessaire. Si votre conception de sauvegarde inclut des sauvegardes hebdomadaires complètes et des sauvegardes quotidiennes différentielles, le numéro d'unité logique de journal doit être supérieur à la valeur d'une semaine entière d'espace de fichier journal pour permettre la sauvegarde et la relecture lors de la restauration.

Déplacements de boîte aux lettres

Le déplacement de boîtes aux lettres est un facteur de capacité principal à prendre en compte pour les déploiements de boîte aux lettres volumineuse. De nombreuses grandes sociétés déplacent un pourcentage de leurs utilisateurs sur une base nocturne ou hebdomadaire vers les différents serveurs, sites ou bases de données. Si votre organisation effectue cela, il se peut que vous vouliez apporter une capacité supplémentaire au numéro d'unité logique du journal pour prendre en charge les mouvements d'utilisateurs. Bien que le serveur source enregistre les suppressions d'enregistrements, qui sont petits, le serveur cible doit d'abord écrire toutes les données transférées dans les journaux des transactions. Si vous générez 10 Go de fichiers journaux en un jour et que vous conservez une mémoire tampon de 30 Go pendant 3 jours, le déplacement de 50 boîtes aux lettres de 2 Go (100 Go) remplit votre numéro d'unité logique de journal et entraîne un temps d'arrêt. Dans de tels cas, vous devez probablement affecter des capacités supplémentaires aux numéros d'unité logique de journal pour faciliter les déplacements de vos boîtes aux lettres.

Facteur de croissance des fichiers journaux

Pour la plupart des déploiements de serveurs de transport Edge, il est recommandé d'ajouter un facteur de traitement de 20 % à la taille des fichiers journaux (une fois tous les autres facteurs pris en compte) lors de la création d'un numéro d'unité logique de fichier journal pour s'assurer d'une capacité suffisante en cas de génération de fichiers journaux imprévue.

Exemple de planification de capacité de boîtes aux lettres

L'exemple suivant montre le dimensionnement approprié pour un environnement englobant 4 000 boîtes aux lettres au profil de message lourd de 1 Go sur un seul serveur de boîtes aux lettres en cluster dans un environnement de réplication continue en cluster (CCR). Ces boîtes aux lettres reçoivent en moyenne 50 Mo de messages par semaine, avec une taille moyenne de message de 50 Ko. Le tableau suivant fournit des exemples de valeur qui déterminent la taille de boîte aux lettres réelle.

Exemples de valeur pour le calcul de la taille de boîte aux lettres réelle sur le disque

Taille de boîte aux lettres	Taille de conteneur de dépôt (2 semaines)	Espaces blancs	Taille totale sur le disque
1 Go	104 Mo (2 × 52 Mo)	7,3 Mo	1,11 Go (+ 11 %)

Dans cet environnement, chaque utilisateur consomme 1,11 Go d'espace disque. Comme la taille maximale de base de données recommandée dans un environnement de CCR est de 200 Go, le serveur ne doit pas héberger plus de 180 boîtes aux lettres par base de données. Pour prendre en charge 4 000 boîtes aux lettres, 23 bases de données sont nécessaires et cet environnement comprend également 23 groupes de stockage. Comme un environnement de CCR requiert une base de données par groupe de stockage, chaque base de données se trouve dans son propre groupe de stockage. Cela aboutit à un nombre final de boîtes aux lettres par groupe de stockage de 174. Sur la base du nombre de boîtes aux lettres et de leur taille actuelle, la taille de la base de données est de 193 Go, comme indiqué dans le tableau suivant.

Besoins en capacité des bases de données

Boîtes aux lettres par base de données	Nombre total de boîtes aux lettres	Besoin en taille des bases de données
174	23	193 Go

Pour s'assurer que le serveur de boîtes aux lettres ne maintient aucune interruption due à des problèmes d'attribution d'espace, la taille des fichiers journaux des transactions doit également être définie de manière à s'adapter à tous les fichiers journaux qui seront générés au cours du jeu de sauvegardes. De nombreuses organisations utilisant une stratégie de sauvegarde complète quotidienne prévoient trois fois la vitesse de génération de journaux quotidiens en cas d'échec de sauvegarde. En cas d'utilisation d'une sauvegarde hebdomadaire complète, puis d'une sauvegarde différentielle ou incrémentielle, une capacité de journal d'au moins une semaine est requise pour gérer la restauration. Sachant qu'une boîte aux lettres de profil de messages très lourde génère une moyenne de 42 fichiers journaux des transactions par jour, un serveur gérant 4 000 boîtes aux lettres génèrera 168 000 fichiers journaux des transactions par jour. Cela signifie que chaque groupe de stockage génèrera 7 304 fichiers journaux. Dix pour cent des boîtes aux lettres sont déplacées par semaine sur un seul jour (le samedi) et le régime de sauvegarde prévoit des sauvegardes hebdomadaires complètes et quotidiennes incrémentielles. En outre, le serveur peut tolérer trois jours sans troncature de journaux. Comme indiqué dans le tableau suivant, ce serveur requiert 38,8 Go d'espace pour chaque groupe de stockage.

Besoins en capacité des fichiers journaux

Journaux par groupe de stockage	Taille de fichier journal	Taille de journal quotidien	Taille de déplacement de boîte aux lettres	Taille de restauration incrémentielle	Besoins en taille des fichiers journaux
7,304	1 Mo	7,13 Go	17 Go (17 × 1 Go)	21,4 Go (3 × 7,13 Go)	38,8 Go (17.4 + 21.4)

Le numéro d'unité logique du journal des transactions doit avoir une capacité suffisante pour gérer les journaux générés par l'opération de déplacement de boîte aux lettres et disposer d'un espace suffisant pour restaurer les journaux d'une semaine entière.

E/S transactionnelles

Les E/S transactionnelles correspondent aux E/S disque provoquées par les utilisateurs qui utilisent le serveur. Par exemple, la réception, l'envoi et la suppression d'éléments entraînent des E/S disque. Les utilisateurs de Microsoft Outlook qui n'utilisent pas le mode Exchange mis en cache sont directement affectés par une latence disque médiocre, ce qui constitue l'un des principaux problèmes liés à la conception du stockage. Pour le stockage, les besoins en E/S transactionnelles ont été réduits et, avec la réplication continue, une haute disponibilité n'implique plus nécessairement l'utilisation d'un stockage Fibre Channel coûteux (même si cela reste une bonne solution).

Présentation des ESPS

Dans les versions précédentes d'Exchange Server, l'une des mesures clés nécessaires au dimensionnement du stockage est la quantité d'E/S de base de données par seconde (ESPS) consommée par chaque utilisateur. Pour mesurer les ESPS de vos utilisateurs, prenez le nombre d'E/S (que ce soit en lecture ou en écriture) du numéro d'unité logique de base de données d'un groupe de stockage et divisez-le par le nombre d'utilisateurs dans le groupe de stockage. Par exemple, 1 000 utilisateurs peuvent engendrer 1 000 E/S sur le numéro d'unité logique de base de données indiquant que l'ESPS est de 1,0 par utilisateur.

Mesure des ESPS de ligne de base

Si vous utilisez une version antérieure d'Exchange Server et avez calculé vos ESPS de ligne de base, n'oubliez pas qu'Exchange 2007 affecte votre ligne de base de deux manières :

• Le nombre d'utilisateurs sur le serveur a un impact sur le cache global de base de données par utilisateur.

• Le volume de RAM influence l'accroissement de la taille de votre cache de base de données et un cache de base de données plus important entraîne un nombre d'opérations de lecture réussies plus important également, réduisant ainsi les E/S en lecture de votre base de données.

Il n'est cependant pas suffisant de connaître vos ESPS sur un serveur spécifique pour planifier toute une entreprise car le volume de RAM, le nombre d'utilisateurs et le nombre de groupes de stockage sont probablement différents sur chaque serveur. Lorsque vous disposez des chiffres ESPS réels, appliquez toujours un facteur de traitement des E/S de 20 % dans vos calculs pour ajouter une marge. Vous ne voulez pas d'une expérience utilisateur limitée lorsque l'activité est plus intense que la normale.

Cache de base de données

Un système d'exploitation Windows Server 64 bits exécutant la version 64 bits d'Exchange 2007 augmente considérablement l'espace d'adressage virtuel et permet à Exchange d'augmenter son cache de base de données, de réduire les E/S en lecture de la base de données et d'activer jusqu'à 50 bases de données par serveur.

La diminution de lecture de la base de données dépend du volume du cache de base de données disponible sur le serveur et du profil de message utilisateur. Pour obtenir des recommandations sur la mémoire et les groupes de stockage, consultez la rubrique Planification des configurations de processeur. En suivant ces instructions, la réduction des E/S transactionnelles peut atteindre jusqu'à 70 % sur Exchange 2003. Le volume du cache de base de données par utilisateur est un facteur clé de la réduction réelle des E/S.

Le tableau suivant illustre l'augmentation du cache de base de données réel par utilisateur en comparant la valeur par défaut de 900 Mo dans Exchange 2003, par rapport aux 5 Mo du cache de base de données par utilisateur dans Exchange 2007. Ce cache de base de données supplémentaire augmente le nombre d'opérations de lecture réussies dans le cache, réduisant ainsi les lectures de la base de données au niveau disque.

Tailles de cache de base de données en fonction du nombre de boîtes aux lettres

Nombre de boîtes aux lettres	Cache de base de données/Boîte aux lettres (Mo) Exchange 2003	Cache de base de données/Boîte aux lettres (Mo) Exchange 2007	Augmentation du cache de base de données dans Exchange 2003
4,000	0.225	5	23 fois
2,000	0.45	5	11 fois
1,000	0.9	5	6 fois
500	1.8	5	3 fois

Prévision des ESPS de ligne de base d'Exchange 2007

Les deux principaux facteurs utilisables pour prévoir les ESPS d'une base de données Exchange 2007 sont le volume du cache de base de données par utilisateur et le nombre de messages que chaque utilisateur envoie et reçoit quotidiennement. La formule suivante est basée sur un travailleur standard qui utilise Office Outlook 2007 en mode Exchange mis en cache et des tests ont montré qu'elle offrait une précision de +/20 %. D'autres types de clients et de scénarios d'utilisation peuvent produire des résultats imprécis. Les prévisions ne valent que pour les tailles de cache de base de données d'utilisateur entre 2 Mo et 5 Mo. La formule n'a pas été validée avec des utilisateurs envoyant et recevant plus de 150 messages par jour. La taille de message moyenne pour la validation de la formule était de 50 Ko mais la taille de message n'est pas un facteur déterminant pour le calcul des ESPS.

Le tableau suivant fournit des valeurs estimées pour les ESPS par utilisateur que vous pouvez utiliser pour prévoir les besoins en ESPS Exchange 2007 de votre ligne de base.

Cache de base de données et estimation des ESPS par utilisateur basée sur un profil utilisateur et l'activité de messagerie

Type d’utilisateur (profil d’utilisation)	Envoyer/recevoir approximativement 50 Ko de taille de message par jour	Cache de base de données par utilisateur	Estimation des ESPS par utilisateur
Light	5 envois/20 réceptions	2 Mo	0.11
Moyen	10 envois/40 réceptions	3,5 Mo	0.18
Très lourd	20 envois/80 réceptions	5 Mo	0.32
Très lourd	30 envois/120 réceptions	5 Mo	0.48
Extrêmement lourd	40 envois/160 réceptions	5 Mo	0.64

Pour estimer la taille de cache de base de données, soustrayez 2,048 Mo, ou 3,072 Mo si vous utilisez une réplication continue locale (LCR) de la quantité totale de mémoire dont dispose le serveur Exchange, puis divisez cette quantité par le nombre d'utilisateurs. Par exemple, pour un serveur avec 3,000 utilisateurs et 16 Go de RAM, déduisez 2 Go pour le système, ce qui laisse 14 Go de RAM, soit 4.66 Mo par utilisateur (14 Go ÷ 3,000 = 4.66 Mo).

En sachant que la taille de cache de base de données moyenne par utilisateur est de 4.66 Mo et que le nombre moyen de messages envoyés et reçus par jour est de 60, vous pouvez estimer les lectures et écritures dans la base de données :

• Lectures de base de données   Multipliez les 60 messages par jour par 0,0048, ce qui donne 0,288. Ensuite, prenez la taille du cache de base de données par boîte aux lettres (4,66 Mo) à la puissance -0,65 (5 ^ -0,65), ce qui donne 0,3622. Enfin, multipliez les deux chiffres, ce qui donne 0,104 lectures de base de données par utilisateur (0,288 × 0,3622 = 0,104).

• Écritures de base de données   Multipliez le nombre de messages par utilisateur (60) par 0,00152, soit 0,0912 écritures de base de données par utilisateur.

La formule à utiliser est la suivante :

((0.0048 × M) × (D ^ -0,65)) + (0,00152 × M) = total d'ESPS de base de données

où M est le nombre de messages et D la taille de cache de base de données par utilisateur. Le nombre total d'ESPS de base de données par utilisateur est la somme des lectures et des écritures qui, dans cet exemple, est 0,189 ESPS :

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

Le graphique suivant indique les réductions de lecture et d'écriture de base de données obtenues lors de l'exécution d'Exchange 2007 avec 4 000 boîtes aux lettres à 250 Mo, en simulant Outlook 2007 en mode Exchange mis en cache et la mémoire de serveur recommandée.

Réduction d'ESPS dans Exchange Server 2007 en comparaison avec Exchange Serveur 2003

Effet des clients en mode en ligne

Contrairement aux clients en mode Exchange mis en cache, toutes les opérations clientes en mode en ligne se produisent sur la base de données. Les opérations d'E/S de lecture augmentent donc dans la base de données. Les instructions suivantes ont donc été établies si la majorité des clients opèrent en mode en ligne :

• Les clients en mode en ligne de 250 Mo augmenteront les opérations de lecture de base de données par un facteur de 1,5 en comparaison avec les clients en mode Exchange mis en cache. En dessous de 250 Mo, l'impact est négligeable.

• Comme la taille de boîte aux lettres double, les ESPS de lecture de base de données doublent également (en supposant que la distribution égale des éléments entre les dossiers clés reste identique).

Le graphique suivant présente les ESPS en fonction de la taille de boîte aux lettres.

Les ESPS de lecture de base de données augmentent avec la taille de la boîte aux lettres

Des tests ont également démontré que l'augmentation du cache de base de données au-delà de 5 Mo par boîte aux lettres ne réduit pas de manière significative les besoins en E/S de lecture de base de données. Le graphique suivant décrit des boîtes aux lettres de 2 Go utilisant les clients en mode en ligne et les conséquences de l'augmentation du cache au-delà de 5 Mo sur la réduction des besoins en E/S de lecture de base de données.

Les ESPS de lecture de base de données diminuent alors que la taille du cache de la boîte aux lettres augmente

En fonction de ces données, deux recommandations peuvent être faites :

• Déployez les clients en mode mis en cache le cas échéant. Pour plus d'informations, consultez la rubrique « Nombre d'éléments par dossier » ci-après.

• Vérifiez que les besoins en E/S sont pris en compte lors de la conception du stockage de base de données.

Pour des facteurs d'ESPS supplémentaires, tels que les clients tiers, consultez le site Web sur l'optimisation du stockage pour Exchange Server 2003.

Ratios de lecture/écriture de base de données

Dans Exchange 2003, le ratio d'écritures par rapport aux lectures de base de données équivaut généralement à 2:1 ou 66 % de lectures. Avec Exchange 2007, un cache de base de données important réduit le nombre de lectures dans la base de données sur disque, ce qui entraîne une réduction des lectures en tant que pourcentage des E/S totales. Si vous vous conformez à nos recommandations sur la mémoire et si vous utilisez le mode Exchange mis en cache, le ratio lectures/écritures doit être proche de 1:1 ou 50 % de lectures.

Lors de l'utilisation d'Outlook en mode en ligne ou lors de l'utilisation de moteurs de recherche de bureau, le ratio lectures/écritures augmente légèrement en ce qui concerne les lectures (en fonction de la taille de la boîte aux lettres). Le fait d'avoir plus d'écritures dans le pourcentage des E/S totales est déterminant dans le choix d'un type de technologie RAID (redundant array of independent disks) entraînant des coûts considérables associés aux écritures, tels que RAID5 ou RAID6. Pour plus d'informations sur la sélection de la solution RAID appropriée pour vos serveurs, consultez la rubrique Technologie de stockage.

Journal du ratio de base de données

Dans Exchange 2003, un journal des transactions d'un groupe de stockage requiert environ 10 % du total des E/S des bases de données du groupe de stockage. Par exemple, si le numéro d'unité logique de base de données utilise 1 000 E/S, le numéro d'unité logique de journal utilise environ 100 E/S. Une réduction des lectures de la base de données dans Exchange 2007 associée à une taille de fichier journal inférieure et à la possibilité d'avoir plus de groupes de stockage, le ratio d'écritures base de données/journal est d'environ 3:4. Par exemple, si le numéro d'unité logique de base de données consomme 500 E/S en écriture, le numéro d'unité logique de journal consomme environ 375 E/S en écriture.

Après la mesure ou la prévision des E/S de journal transactionnelles, appliquez 20 % de traitement supplémentaire aux E/S pour garantir un espace adéquat afin d'anticiper sur les périodes plus chargées que la normale. En outre, lors de l'utilisation de la réplication en continu, les journaux des transactions clôturés doivent être lus et envoyés dans un autre emplacement. Ce traitement équivaut à 10 % supplémentaires de lectures de journal. Si le journal des transactions d'un groupe de stockage consomme 375 E/S en écriture, vous pouvez prévoir 37,5 E/S en lecture supplémentaires lors de l'utilisation de la réplication continue.

Nombre d'éléments par dossier

Impact sur les performances des nombres élevés d'éléments et des affichages restreints explique la manière dont le nombre d'éléments dans vos dossiers importants, ainsi que les type et mode de client utilisés, peuvent affecter les performances de disque de certains utilisateurs.

L'utilisation d'Outlook 2007 en mode Exchange mis en cache permet de réduire les E/S de serveur. La synchronisation de boîte aux lettres initiale est une opération coûteuse, mais au fil du temps, au gré de l'accroissement de la taille de la boîte aux lettres, la charge du sous-système disque passe du serveur Exchange au client Outlook. Cela signifie qu'un nombre important d'éléments dans la boîte de réception d'un utilisateur ou la recherche d'une boîte aux lettres par un utilisateur aura un impact moindre sur le serveur. Cela signifie également que les utilisateurs d'Exchange en mode mis en cache dotés de boîtes aux lettres volumineuses peuvent requérir l'utilisation d'ordinateurs plus rapides que ceux dotés de petites boîtes aux lettres (en fonction du seuil utilisateur individuel concernant les performances acceptables). Lorsque vous déployez des ordinateurs clients exécutant Outlook 2007 en mode Exchange mis en cache, prenez en compte les aspects suivants en relation avec les tailles des boîtes aux lettres/fichiers .OST :

• Jusqu'à 5 gigaoctets (Go) : cette taille doit fournir une bonne expérience utilisateur sur la plupart du matériel.

• Entre 5 Go et 10 Go : cette taille dépend généralement du matériel. Par conséquent, si vous disposez d'un disque dur rapide et d'une quantité importante de RAM, votre expérience sera meilleure. Avec les disques durs plus lents, tels que ceux généralement trouvés sur les ordinateurs portables ou les disques SSD d'ancienne génération, les applications peuvent être temporairement mises en pause lorsque les disques répondent.

• Plus de 10 Go : à partir de cette taille, des pauses courtes commencent à survenir sur la plupart du matériel.

• Très grande taille, par exemple 25 Go ou plus : cette taille accroît la fréquence des pauses courtes, en particulier lors du téléchargement des nouveaux messages électroniques. Vous pouvez également utiliser les groupes d'envoi/de réception pour synchroniser manuellement votre messagerie.

Notes

Ces instructions sont basées sur l'installation d'une mise à jour cumulative pour Outlook 2007 Service Pack 1 ou une version ultérieure, comme décrit dans l'article 961752 de la Base de connaissances Microsoft, Description of the Outlook 2007 hotfix package (Outlook.msp): February 24, 2009 (en anglais).

Si vous rencontrez des problèmes de performances avec votre Outlook 2007 dans le déploiement en mode Exchange mis en cache, consultez l'article 940226 de la Base de connaissances, How to troubleshoot performance issues in Outlook 2007 (en anglais).

Outlook Web Access et Outlook en mode en ligne stockent des indices et recherchent sur la copie des données du serveur. Pour des boîtes aux lettres dont la taille est modérée, cela double les ESPS par boîte aux lettres par rapport à un client mode Exchange mis en cache de taille équivalente. Les ESPS par boîte aux lettres de boîtes aux lettres volumineuses sont encore plus importantes. La première fois où vous triez une vue d'une nouvelle manière, un index est créé, provoquant de nombreuses lectures d'E/S sur le numéro d'unité logique de base de données. Des tris supplémentaires sur un index actif sont peu coûteux.

Un scénario plus problématique est celui où un utilisateur dépasse le nombre d'index pouvant être stockés par Exchange qui est de 11 pour Exchange 2007. Lorsque l'utilisateur sélectionne une nouvelle sorte de tri, créant un 12ème index, cela engendre des E/S disque supplémentaires. Comme l'index n'est pas stocké, ce coût des E/S disque est occasionné à chaque tri. En raison du nombre élevé d'E/S que ce scénario peut générer, il est fortement recommandé de ne pas stocker plus de 20 000 éléments dans les dossiers principaux tels que les dossiers Boîte de réception et Éléments envoyés. La création de dossiers de niveau supérieur supplémentaires ou de sous-dossiers sous les dossiers Boîte de réception et Éléments envoyés, réduit considérablement les coûts associés à la création de cet index, aussi longtemps que le nombre d'éléments d'un dossier n'excède pas 20 000. Pour plus d'informations sur le nombre d'éléments affectant les performances du serveur de boîtes aux lettres, consultez l'article Recommended Mailbox Size Limits (en anglais) et la rubrique Impact sur les performances des nombres élevés d'éléments et des affichages restreints.

Notes

UNRESOLVED_TOKEN_VAL(exBlog)

Pour plus d'informations sur les améliorations disponibles, consultez l'article 968009 de la Base de connaissances, Outlook 2007 improvements in the February 2009 cumulative update (en anglais).

E/S non transactionnelles

Les E/S transactionnelles se produisent en réponse à l'action directe d'un utilisateur, bénéficient en général de la priorité la plus haute et constituent l'aspect essentiel de la conception du stockage. La réduction des E/S transactionnelles donne plus d'importance aux E/S non transactionnelles. Avec d'importantes boîtes aux lettres, en particulier dans le cas d'une boîte aux lettres de 2 Go, de nombreuses entreprises ne doublent pas les capacités utilisateur, mais, dans certains cas, les décuplent. Un tel exemple consiste à passer de 200 Mo à 2 Go. Lorsqu'une telle augmentation est vérifiée dans le volume des données du disque, vous devez prendre en compte les E/S non transactionnelles lors de la planification de votre conception de stockage.

Indexation de contenu

Dans Exchange 2007, les messages sont indexés lorsqu'ils sont reçus, entraînant un traitement des E/S disque peu important. La recherche dans l'index d'Exchange 2007 est environ 30 fois plus rapide que dans Exchange 2003.

Gestion des enregistrements de messagerie

La Gestion des enregistrements de messagerie (MRM) est une nouvelle fonctionnalité d'Exchange 2007 permettant aux administrateurs et aux utilisateurs de gérer leurs boîtes aux lettres. Les stratégies peuvent être définies pour déplacer ou supprimer le courrier respectant des seuils spécifiques tels que celui de l'âge. La MRM est une analyse planifiée s'exécutant sur la base de données dans une opération de lecture synchrone similaire à la sauvegarde et à la maintenance en ligne. L'espace disque requis pour la MRM dépend du nombre d'éléments requérant une action telle qu'une suppression ou un déplacement.

Il est recommandé que la MRM ne s'exécute pas en même temps que la sauvegarde ou la maintenance en ligne. Si vous utilisez la réplication continue, vous pouvez décharger des sauvegardes VSS (Volume Shadow Copy Service) sur la copie passive, ce qui libère du temps pour la maintenance en ligne et la MRM pour qu'elles ne s'affectent pas entre elles et n'affectent pas les utilisateurs.

Maintenance en ligne

De nombreuses actions sont exécutées lorsque la base de données exécute la maintenance en ligne, telles que la suppression définitive des éléments supprimés et une défragmentation en ligne de la base de données. La maintenance implique des lectures, alors que la défragmentation en ligne engendre des lectures et des écritures. Le temps nécessaire à la réalisation de la maintenance est proportionnel à la taille de la base de données et peut être un facteur restrictif sur la croissance autorisée des bases de données. Pour plus d'informations sur la maintenance en ligne, consultez la page Web relative aux Processus de stockage en arrière-plan Partie I.

Notes

UNRESOLVED_TOKEN_VAL(exBlog) 

Sauvegarde et restauration

L'administrateur dispose d'un grand nombre de méthodes de sauvegarde et de restauration. La mesure clé de la sauvegarde et de la restauration est le débit ou le nombre de mégaoctets par seconde pouvant être copiés depuis et vers vos numéros d'unité logique de production. Une fois le débit calculé, vous devez décider s'il est suffisant pour votre contrat de niveau de service (SLA) de sauvegarde et de restauration. Par exemple, si vous devez effectuer la sauvegarde en 4 heures, il se peut que vous deviez ajouter du matériel pour y arriver. En fonction de votre configuration matérielle, des gains de performances peuvent être effectués en modifiant la taille d'unité d'allocation. Cela peut être utile pour les sauvegardes en ligne en continu et la vérification de l'intégrité des Utilitaires de base de données Exchange (Eseutil) effectuée lors d'une sauvegarde VSS.

Avec 2 000 utilisateurs sur un serveur, le passage d'une boîte aux lettres de 200 Mo à 2 Go décuple la taille de la base de données. De nombreux administrateurs ne sont pas habitués à gérer des volumes de données importants sur un seul serveur. Considérez un serveur comptant 2 000 boîtes aux lettres de 2 Go. Avec le traitement décrit précédemment, les 4 To de données sont dépassés. En supposant que la vitesse de sauvegarde soit de 175 Go/heure (48 Mo/min), la sauvegarde du serveur durerait au moins 23 heures. Une alternative aux serveurs n'utilisant pas la LCR ou la CCR peut consister à réaliser une sauvegarde complète du septième des bases de données quotidiennement et une sauvegarde incrémentielle pour le reste, comme exposé dans le tableau suivant.

Exemple de routine de sauvegarde hebdomadaire

Type de sauvegarde	Jour 1	Jour 2	Jour 3	Jour 4	Jour 5	Jour 6	Jour 7
Complet	BDD 1-2	BDD 3-4	BDD 5-6	BDD 7-8	BDD 9-10	BDD 11-12	BDD 13-14
Incrémentiel	BDD 3-14	BDD 1-2 BDD 5-14	BDD 1-4 BDD 7-14	BDD 1-6 BDD 9-14	BDD 1-8 BDD 11-14	BDD 1-10 BDD 13-14	BDD 1-12

Comme indiqué dans le tableau précédent, le volume total de données sauvegardées la nuit avoisine 650 Go, ce qui nécessiterait 3,7 heures, sur la base d'un taux de 175 Go/heure. Certaines solutions peuvent générer un débit plus ou moins important. Toutefois, les grandes boîtes aux lettres peuvent nécessiter des approches différentes.

Avec la LCR et la CCR, la copie passive est la première ligne de défense. Vous ne procédez à une restauration à partir d'une sauvegarde qu'en cas de défaillance ou d'indisponibilité des copies active et passive. La récupération correspondant à plusieurs jours de génération de journaux incrémentiels peut allonger la durée de récupération. Pour cette raison, la sauvegarde incrémentielle est rarement utilisée dans une solution de récupération rapide, telle que la CCR ou la duplication VSS. Avec la duplication VSS, la récupération des données est très rapide et l'ajout d'une courte durée pour relire les journaux est acceptable pour conserver les temps de sauvegarde prévus par le contrat SLA de sauvegarde.

Sauvegarde en continu en ligne

Avec les sauvegardes continues, il est recommandé de séparer les E/S en continu (sources et cibles) de sorte que plusieurs groupes de stockage en cours de sauvegarde ne réclament pas les mêmes ressources disque. Si l'unité cible est un disque ou une bande, une limite de débit unique sera établie sur les disques physiques et les contrôleurs pour chaque solution matérielle. Il peut s'avérer nécessaire d'isoler des groupes de stockage d'autres groupes de stockage pour maximiser le nombre d'opérations de sauvegarde simultanées, ainsi que le débit pour minimiser la taille de la fenêtre de sauvegarde. Le tableau suivant présente un exemple de deux sauvegardes simultanées de 14 bases de données.

Exemple de routine de sauvegarde simultanée

Nombre de sauvegarde	Numéro d'unité logique 1	Numéro d'unité logique 2	Numéro d'unité logique 3	Numéro d'unité logique 4	Numéro d'unité logique 5	Numéro d'unité logique 6	Numéro d'unité logique 7
Première sauvegarde	groupe de stockage (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
Deuxième sauvegarde	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

Vous pouvez exécuter des sauvegardes en continu simultanément, une à partir de chaque unité de numéro logique, si vous isolez vos unités de numéro logique de groupe de stockage les unes des autres, comme indiqué dans le tableau ci-avant. Les tâches de sauvegarde doivent se terminer sur le premier groupe de stockage de chaque numéro d'unité logique avant que la sauvegarde du deuxième groupe de stockage ne commence, isolant les flux de sauvegarde. Deux tâches de sauvegarde en continu sur les mêmes disques physiques ne peuvent pas être effectuées deux fois plus rapidement, mais leur exécution doit être plus rapide qu'une seule tâche de sauvegarde en continu en termes de Mo sauvegardés par seconde.

Sauvegarde VSS

Exchange 2007 utilise les services VSS inclus dans Windows Server 2003 pour prendre des clichés instantanés de volume des fichiers journaux des transactions et des bases de données. Pour plus d'informations sur le service VSS, notamment les techniques de duplication et d'instantané, consultez la page Web relative aux meilleures pratiques concernant l'utilisation des services VSS avec Exchange Server 2003. Une nouveauté dans Exchange 2007 est la possibilité d'effectuer des sauvegardes VSS de la copie passive des groupes de stockage s'exécutant dans un environnement de LCR ou de CCR. Dans ces environnements, la prise d'un instantané VSS à partir de la copie passive déplace la charge du disque sur les numéros d'unité logique actifs durant la phase de contrôle d'intégrité par somme de contrôle de la sauvegarde et la copie subséquente sur bande ou sur disque. Elle libère également du temps sur les numéros d'unité logique actifs pour effectuer la maintenance en ligne, la MRM et d'autres tâches.

Numéros d'unité logique (LUN) et disques physiques

Souvent, le disque physique, ou numéro d'unité logique (LUN), reconnu par le système d’exploitation est extrait du matériel utilisé pour présenter le disque au système d’exploitation. Pour des raisons de performance et de récupération, il a toujours été essentiel de séparer les fichiers journaux de transactions des fichiers de base de données aux niveaux du numéro d’unité logique et du disque physique. Le mélange d'E/S disque aléatoires et séquentielles sur le même disque physique réduit les performances de manière significative et, du point de vue de la restauration, la séparation des fichiers journaux d’un groupe de stockage des fichiers de base de données garantit qu’une défaillance irrémédiable d'un ensemble de disques physiques n'occasionne pas la perte des fichiers de base de données et des fichiers journaux.

Dans Exchange 2007, il est recommandé de placer toutes les bases de données dans un groupe de stockage sur le même numéro d’unité logique. Une pratique également recommandée est de ne pas placer plus d’une base de données dans chaque groupe de stockage. Les E/S de base de données Exchange sont aléatoires et la plupart des sous-systèmes de stockage bénéficient du fait que les disques physiques exécutent la même charge de travail. De nombreuses baies de stockage sont conçues de sorte que plusieurs disques physiques sont d’abord rassemblés en groupes de disques, puis les numéros d’unité logique sont créés depuis l’espace disponible dans ce groupe de disques et distribués de manière équitable entre les disques physiques. Il est acceptable que les disques physiques qui sauvegardent le numéro d’unité logique de la base de données d'un groupe de stockage sauvegardent également d’autres numéros d’unité logique qui hébergent les bases de données d’autres groupes de stockage et serveurs. De même, il n’est pas essentiel d’isoler chaque numéro d’unité logique du journal des transactions d’un groupe de stockage sur des piles physiques distinctes, même si la perte d'E/S séquentielles risque de dégrader légèrement les performances.

Si le nombre maximal de 50 groupes de stockage est configuré sur un seul serveur, chaque groupe de stockage requiert ses propres numéros d’unité logique du journal des transactions et de base de données. Ce nombre dépassant le nombre de lettres de lecteurs disponibles, les points de montage de volume de système de fichiers NTFS doivent être utilisés. Cinquante groupes de stockage configurés pour une réplication continue requièrent 200 numéros d’unité logique, ce qui pourrait dépasser certaines valeurs maximales de baies de stockage, particulièrement dans le cas d'une LCR où les 200 numéros d’unité logique doivent être présentés à un seul serveur. À mesure que le nombre de numéros d’unité logique augmente, l’analyse devient encore plus importante parce qu'un espace disque insuffisant entraîne le démontage du groupe de stockage.

Conception de numéros d'unité logique

Dans de nombreux cas, le numéro d'unité logique, reconnu par le système d'exploitation, est extrait du matériel physique que constitue le « disque ». Il a toujours été très important de séparer les journaux des transactions de la base de données au niveau du numéro d'unité logique et du disque physique à des fins de performances et de récupération. Dans certaines baies de stockage, le mélange d'E/S aléatoires et séquentielles sur les mêmes disques physiques peut réduire les performances. Dans une optique de récupération, la séparation des journaux des transactions et des bases de données d'un groupe de stockage garantit qu'une défaillance irrémédiable d'un ensemble spécifique de disques physiques n'entraîne pas de perte de la base de données et des journaux des transactions.

Les E/S de la base de données Exchange sont aléatoires et la plupart des sous-systèmes de stockage sont avantagés lorsque les disques physiques traitent la même charge de travail. De nombreuses baies de stockage utilisent un stockage virtuel de sorte que de nombreux disques physiques sont d’abord rassemblés en un groupe de disques, puis des numéros d’unité logique sont créés en fonction de l’espace disponible dans ce groupe de disques et distribués uniformément entre les disques physiques. Lorsque la réplication continue n'est pas utilisée, il est acceptable que les disques physiques qui sauvegardent le numéro d’unité logique de la base de données d'un groupe de stockage sauvegardent également d’autres numéros d’unité logique qui hébergent les bases de données d’autres groupes de stockage et serveurs. De même, il n’est pas essentiel d’isoler chaque numéro d’unité logique du journal des transactions d’un groupe de stockage sur des piles physiques distinctes, même si la perte d'E/S séquentielles risque de dégrader légèrement les performances. Il est important de séparer les numéros d'unité logique du journal et de la base de données du même groupe de stockage sur des disques physiques distincts. Il n'est pas réaliste de consacrer deux ou quatre disques physiques de 500 Go au numéro d'unité logique du journal des transactions d'un seul groupe de stockage lorsqu'il vous faut 30 ESPS et 5 % de la capacité.

S'il existe de nombreuses manières de concevoir les numéros d'unité logique dans Exchange 2007, il est néanmoins recommandé d'utiliser les deux conceptions suivantes pour limiter la complexité :

• deux numéros d'unité logique par groupe de stockage ;

• deux numéros d'unité logique par jeu de sauvegarde.

Deux numéros d'unité logique par groupe de stockage

La création de deux numéros d'unité logique (un pour les journaux et un pour les bases de données) d'un groupe de stockage constituait la meilleure pratique standard pour Exchange 2003. Avec Exchange 2007 et dans les cas maximaux de 50 groupes de stockage, le nombre de numéros d'unité logique fournis dépend de votre stratégie de sauvegarde. Si votre objectif de temps de récupération (RTO) est très court ou si vous utilisez des clones VSS pour une récupération rapide, il peut être judicieux de placer chaque groupe de stockage dans son propre numéro d'unité logique de journal des transactions et son numéro d'unité logique de base de données. Comme cette approche augmente le nombre de lettres de lecteur disponibles, des points de montage de volume doivent être utilisés.

Les avantages de cette stratégie comprennent :

• Activation du service VSS basé sur le matériel au niveau du groupe de stockage, en fournissant une sauvegarde et une restauration d'un seul groupe de stockage

• Flexibilité pour isoler les performances entre les groupes de stockage

• Fiabilité augmentée. Un problème de capacité, d'endommagement ou de virus sur un seul numéro d'unité logique aura uniquement un impact sur un seul et unique groupe de stockage.

Les problèmes concernant cette stratégie comprennent :

• Cinquante groupes de stockage utilisant la réplication continue requièrent 200 numéros d’unité logique, ce qui pourrait dépasser certaines valeurs maximales de baies de stockage, particulièrement dans le cas de la LCR où les 200 numéros d’unité logique doivent tous être présentés à un seul serveur.

• Un numéro d'unité logique distinct pour chaque groupe de stockage peut engendrer plusieurs numéros d'unité logique par serveur, en augmentant les coûts d'administration.

Deux numéros d'unité logique par ensemble de sauvegardes

Un ensemble de sauvegardes correspond au nombre de bases de données totalement sauvegardées au cours d'une nuit. Une solution exécutant une sauvegarde complète sur 1/7ème des bases de données au cours d'une nuit peut réduire la complexité en plaçant tous les groupes de stockage à sauvegarder sur le même numéro d'unité logique du journal et de la base de données. Cela peut réduire le nombre de numéros d'unité logique sur le serveur.

Les avantages de cette stratégie comprennent :

• Administration de stockage simplifiée car il y a moins de numéros d'unité logique à gérer

• Réduction possible du nombre de tâches de sauvegarde.

Les problèmes concernant cette stratégie comprennent :

• Limitation de la capacité à effectuer des restaurations et des sauvegardes VSS basées sur le matériel.

• Limitation de l'augmentation en capacité de cette stratégie, en raison de la limite de 2 téra-octets sur une partition MBR (Master Boot Record).

Points de montage des volumes

Dans de nombreux cas, tels que des clusters à copie unique (SCC) à plusieurs noeuds, le nombre de numéros d'unité logique nécessaires est supérieur aux lettres de lecteur disponibles. Le cas échéant, vous devez utiliser les points de montage des volumes. Les lettres de lecteur sont une fonctionnalité MS-DOS héritée permettant de reconnaître les partitions ou les disques ; il est préférable de ne pas utiliser un trop grand nombre de lettres de lecteur. Il est plus aisé de placer tous les numéros d'unité logique du journal des transactions et de la base de données sur un point de montage des volumes afin de faciliter l'administration. S'il y a 20 groupes de stockage, chacun avec une base de données, il est difficile de se rappeler la lettre du lecteur hébergeant la base de données 17. Le tableau suivant présente un exemple d'utilisation de points de montage de volume.

Exemple de dossier utilisant des points de montage de volume

Journaux des transactions (L:)	Bases de données (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

Dans cet exemple, L: et P: sont des numéros d'unité logique d'ancrage qui hébergent respectivement tous les numéros d'unité logique des journaux et des bases de données. Chaque dossier sur ces lecteurs est un point de montage de volume pour un numéro d'unité logique distinct.

Service VSS basé sur le matériel

Lors de l'utilisation du service VSS basé sur le matériel, il existe quelques recommandations relatives au placement des données Exchange dans les numéros d'unité logique. Pour une solution VSS basée sur le matériel, chaque numéro d'unité logique de journal des transactions et de base de données doit uniquement héberger les fichiers issus de l'ensemble de sauvegarde choisi. Si vous voulez restaurer un groupe de stockage sans en affecter les autres, vous aurez besoin d'un numéro d'unité logique de journal des transactions et d'un numéro d'unité logique de base de données distincts pour chaque groupe de stockage. Si vous voulez mettre en mode hors connexion d'autres bases de données et groupes de stockage pour restaurer une seule base de données, vous pouvez placer plusieurs groupes de stockage sur un seul numéro d'unité logique de journal des transactions et de base de données.

Service VSS basé sur les logiciels

Lors de l'utilisation du service VSS basé sur le logiciel, en particulier avec des boîtes aux lettres volumineuses et la réplication continue, votre sauvegarde est une stratégie en deux étapes. Tout d'abord, vous prenez un instantané VSS, puis vous transférez les fichiers plats vers le disque ou la bande.

Fiabilité des numéros d'unité logique

Il est important de placer les bases de données et les journaux des transactions d'un groupe de stockage sur des disques physiques distincts pour augmenter la fiabilité. Avec la réplication continue, il est également important de séparer les numéros d'unité logique passifs et actifs dans des stockages totalement différents. Avec la CCR et la LCR, vous voulez une tolérance du stockage au cas où surviendrait une défaillance irréparable du stockage principal.

Exemple de numéro d'unité logique

Considérez le scénario suivant basé sur l'exemple de capacité précédent, qui applique ces informations à la création d'un numéro d'unité logique. Dans cet exemple, le régime de sauvegarde est celui d'une sauvegarde complète quotidienne. Vous voulez activer l'indexation du contenu et l'appliquer au numéro d'unité logique de base de données. Cinq pour cent de 193 Go équivalent environ à 10 Go. Vous devez ajouter cela à la taille finale de votre numéro d'unité logique. Le facteur de croissance pour 193 Go doit représenter 20 % de la taille de base de données finale. 20 % de 193 Go représentent 39 Go. Les tableaux suivants présentent les résultats.

Exemple de valeurs permettant de déterminer la taille des numéros d'unité logique de base de données

Taille de base de données	Facteur de croissance	Indexation du contenu	Taille de numéro d'unité logique de base de données
193 Go	39 Go	10 Go	241 Go

Chaque groupe de stockage crée 7,13 Go de journaux par jour et vous voulez stocker au moins 3 jours de journaux.

Exemple de valeurs permettant de déterminer la taille des numéros d'unité logique de fichier journal

Journaux (1 jour)	Journaux (3 jours)
7,13 Go	21,4 Go

Déplacer une boîte aux lettres

Notre exemple d'organisation déplace 10 % de ses boîtes aux lettres par semaine le samedi. Le numéro d'unité logique de fichier journal doit donc gérer la charge entière en une journée. Un stratégie de déplacement de boîte aux lettres utilisée chez Microsoft consiste à répartir les utilisateurs entrants de façon égale entre les différents groupes de stockage. Cela signifie que le serveur d'exemple avec 4 000 utilisateurs déplace environ 400 utilisateurs chaque samedi. Avec 23 groupes de stockage, chacun d'eux doit recevoir dix-sept boîtes aux lettres de 1 Go, comme indiqué dans le tableau suivant.

Exemple de valeurs permettant de déterminer la taille des numéros d'unité logique de déplacement de fichier journal

Journaux (3 jours)	Déplacements de boîte aux lettres	Taille de numéro d'unité logique de journal
21,4 Go	17,64 Go (17 utilisateurs 1 Go)	46,6 Go (38,8 G0 + 20 %)

Avec cette organisation, vous ne déplacez jamais plus de 17 utilisateurs vers un groupe de stockage le même jour. C'est pourquoi, il est peut-être préférable d'augmenter la taille du numéro d'unité logique de journal dans l'hypothèse où vous devriez déplacer plus de 10 pour cent un jour donné.

Impact de la réplication continue sur la conception du routage

La réplication continue est une nouvelle fonctionnalité d’Exchange 2007 pour laquelle la base de données et les fichiers journaux d’un groupe de stockage sont copiés dans un emplacement secondaire. Lors de la fermeture ou du remplissage de journaux des transactions, ces derniers sont copiés dans un emplacement secondaire, validés, puis relus dans une copie passive de la base de données. Pour la tolérance du stockage, il est recommandé que la copie passive soit placée dans une baie de stockage complètement isolée des numéros d’unité logique de production actifs. Comme vous dépendez de la copie passive pour gérer la charge de production en cas de défaillance, son stockage doit correspondre à la performance et à la capacité de la solution de stockage utilisée pour la copie active du groupe de stockage.

Chaque groupe de stockage ne pouvant contenir qu’une seule base de données lors de l’utilisation de la réplication continue, chaque copie de la base de données requiert quatre numéros d’unité logique. Chaque copie de base de données se trouve dans son propre groupe de stockage, ce qui nécessite un journal et un numéro d’unité logique distincts pour la copie active, et un journal ainsi qu’un numéro d’unité logique distincts pour la copie passive.

Meilleure pratique :

• séparer le stockage en numéros d’unité logique individuels au niveau du matériel et de ne pas créer plusieurs partitions logiques d’un numéro d’unité logique dans le système d’exploitation ;

• séparer les journaux des transactions et les bases de données et les héberger sur des disques physiques distincts pour augmenter la tolérance de pannes ;

• séparer les numéros d’unité logique actifs et passifs sur des baies de stockage complètement distinctes afin que le stockage ne soit pas un point de défaillance unique.

• Si vous hébergez les groupes de stockage ou les bases de données de plusieurs serveurs de boîtes aux lettres en cluster sur la même baie de stockage, vous devez vous assurer que chaque numéro d'unité logique est créé à l'aide de disques physiques distincts.

Votre système de stockage doit également maximiser la tolérance des pannes par la séparation des contrôleurs de stockage sur un bus PCI (Peripheral Component Interconnect) distinct. En outre, vous devez concevoir le stockage pour la copie passive de sorte qu’il corresponde à celui utilisé par la copie active en termes de capacité et de performance. Le stockage de la copie passive est la première ligne de défense en cas de défaillance catastrophique du stockage de la copie active et, en cas de basculement, la copie passive devient la copie active. Placer les numéros d’unité logique de la copie passive sur un matériel de stockage complètement distinct garantit que les actions effectuées sur la copie passive n'affectent pas la copie active.

Un plus grand nombre d'E/S transactionnelles interviennent avec la réplication continue. Ce facteur doit être pris en compte lors du dimensionnement du serveur. Le journal des transactions actif, qui est une écriture séquentielle, doit également lire le journal après sa fermeture et le copier dans le répertoire de mise en quarantaine des numéros d’unité logique du journal des transactions du réplica. Le journal doit être ensuite inspecté à l’emplacement du réplica, puis déplacé vers sa destination finale sur le numéro d’unité logique du réplica. Enfin, le journal est lu et exécuté dans la base de données. Les numéros d’unité logique actifs et ceux du journal des transactions du réplica doivent être lus et écrits par rapport aux opérations d’écriture séquentielle proche de 100 pour cent qui se trouvent sur un serveur de boîtes aux lettres autonome Ce changement de comportement peut nécessiter une évaluation des paramètres du cache de votre contrôleur de stockage. Les paramètres recommandés sont de 25 % pour la lecture et de 75 % pour l’écriture sur un contrôleur de stockage doté d'une batterie de secours.

Réplication continue et taille de base de données

Il est possible de disposer d'une taille de base de données maximale plus élevée lorsque la réplication continue est utilisée. Voici les tailles de base de données maximales recommandées pour Exchange 2007 :

• Bases de données hébergées sur un serveur de boîtes aux lettres sans réplication continue : 100 Go

• Bases de données hébergées sur un serveur de boîtes aux lettres avec réplication continue et Gigabit Ethernet : 200 Go

  Notes

  Des bases de données de grande taille peuvent également nécessiter une technologie de stockage plus récente en cas d'élargissement de la bande passante afin de s'adapter aux scénarios de réparation.

  Important

  La taille maximale réelle de vos bases de données dépend du contrat SLA conclu par votre organisation. Le calcul de la taille maximale de base de données pouvant être sauvegardée et restaurée au cours d'une période donnée aux termes du contrat SLA de votre organisation équivaut à déterminer la taille maximale de vos bases de données.

Options de stockage LCR

La LCR permet l’envoi des journaux sur un serveur unique. En cas de défaillance catastrophique du stockage qui héberge la copie active de la base de données ou les fichiers journaux, l’administrateur peut manuellement activer la copie passive de la base de données. Le stockage de la copie passive doit être complètement séparé du stockage de la copie active. En outre :

• Les cartes du contrôleur doivent être utilisées sur un bus PCI différent.

• Chaque solution de stockage doit avoir son propre onduleur (UPS).

• Chaque solution de stockage doit disposer d'un circuit d'alimentation distinct.

Options de stockage CCR

La CCR permet l’envoi des journaux à un noeud passif dans un cluster avec basculement actif/passif. Par l’envoi des journaux et la conservation de la copie passive sur un serveur totalement distinct, l’impact de fonctionnement est diminué au noeud actif et vous disposez d'une tolérance de pannes sur le serveur.

Lors d’un déploiement de CCR dispersé sur le plan géographique, la copie passive peut être un noeud qui se trouve dans un emplacement physique différent de celui du noeud actif, ce qui permet une tolérance aux pannes du site. Bien que les informations de l’article relatif aux instructions de déploiement pour une réplication de données Exchange Server multi-site soient toujours d'application, la technologie de type pull sous-jacente à la réplication continue implique qu’une latence élevée n’affecte pas l'expérience de l'utilisateur. Cela contraste sensiblement avec la solution de clusters dispersés sur le plan géographique pour laquelle la latence de réplication synchrone affecte le serveur actif de manière négative. Avec la CCR, le processus de réplication peut être exécuté en arrière-plan, augmentant le temps pendant lequel la copie active et la copie passive ne sont pas synchronisées. Toutefois, si une panne affecte la copie active, les messages qui n’ont pas été répliqués sur le noeud passif sont récupérables en raison de la fonction de conteneur de dépôt de transport sur un serveur de transport Hub.

Options de stockage d'un cluster à copie unique

Le matériel utilisé pour un SCC doit être répertorié dans la catégorie de cluster du catalogue de serveur Windows. Le matériel utilisé pour les SCC dispersés sur le plan géographique doit être répertorié dans la catégorie de cluster dispersé sur le plan géographique du catalogue de serveur Windows afin d’être pris en charge.

Un serveur de boîtes aux lettres en cluster utilisant un stockage partagé répond aux mêmes considérations fondamentales relatives au stockage qu’un serveur autonome. En cas d'utilisation de la réplication synchrone, la latence de disque peut être augmentée artificiellement par le processus de réplication. Vous devez être attentif à optimiser les points de réplication dans la baie de stockage. Pour plus d’informations sur la réplication des SCC, consultez la page sur les instructions de déploiement pour la réplication multi-site Exchange Server de données.