Exemple de conception d'un rôle serveur de boîtes aux lettres Exchange 2010

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2016-11-28

Cette rubrique fournit un exemple de détermination des besoins appropriés en mémoire, capacité, E/S et performance de l’unité centrale pour le rôle serveur de boîtes aux lettres et l’architecture qui lui est associée.

Vous pouvez utiliser le Calculateur de configuration requise pour le rôle serveur de boîtes aux lettres dans Exchange Server 2010 pour déterminer la configuration appropriée pour le rôle serveur de boîtes aux lettres en spécifiant votre ensemble de facteurs d’entrée Le calculateur peut déterminer les besoins décrits dans cet exemple. Pour plus d’informations sur ce calculateur (et pour le télécharger), consultez l’article du blog de l’équipe Exchange Server Calculateur des besoins en stockage du rôle serveur de boîtes aux lettres Exchange 2010.

Remarque :
Le contenu de chaque blog et les URL correspondantes peuvent faire l’objet de modifications sans préavis. Le contenu de chaque blog est fourni en l’état sans aucune garantie, et ne confère aucun droit. L’utilisation des exemples de script inclus est soumise aux conditions spécifiées dans les Conditions d’utilisation de Microsoft.

Pour plus d’informations sur la conception de stockage de rôle serveur de boîtes aux lettres, consultez la rubrique Conception du stockage de serveur de boîtes aux lettres.

Cet exemple utilise un scénario impliquant trois copies de base de données et un stockage de type JBOD (just a bunch of disks). Aux fins de cet exemple, considérez les besoins suivants concernant l’architecture :

• Six serveurs de boîte aux lettres participant à un groupe de disponibilité de base de données unique

• Le serveur de boîtes aux lettres Exchange héberge également les rôles serveur de transport Hub et serveur d’accès au client

• Trois copies de base de données de boîtes aux lettres de haute disponibilité, aucune copie retardée de base de données

• Des piles de disques SATA 7,2 K (7 200 tr/min), 1 téraoctet, sont utilisées

• Configuration de stockage JBOD (1 numéro d’unité logique (LUN) / architecture LUN de bases de données)

• Comme architecture de secours, utilisation des fonctions natives de protection des données via la récupération d’élément unique et la résilience de boîte aux lettres

• Un numéro d’unité logique de restauration est déployé pour les opérations de maintenance et de récupération

• Chaque numéro d’unité logique possède au moins 20 % d’espace libre

• La solution doit résister à des défaillances double serveur

• Le seul rôle serveur installé est le serveur de boîtes aux lettres

Contenu de cette rubrique

Besoins en capacité des boîtes aux lettres

Configuration requise pour les copies de base de données

Besoins en mémoire des boîtes aux lettres

Configuration E/S requise pour les boîtes aux lettres

Besoins en processeur des boîtes aux lettres

Besoins en capacité des boîtes aux lettres

L’exemple suivant illustre le dimensionnement approprié d’un environnement comportant 24 000 boîtes aux lettres avec un profil de 100 messages par jour pour un volume de 2 Go, qui sont réparties sur six serveurs de boîtes aux lettres participant à un groupe de disponibilité de base de données, avec trois copies de chaque base de données. Ces boîtes aux lettres reçoivent en moyenne 37 Mo de messages par semaine de cinq jours ouvrés, avec une taille moyenne de message de 75 Ko. La récupération d’élément unique est activée avec une fenêtre de rétention des éléments supprimés de 14 jours. Les calculs suivants sont utilisés pour déterminer la taille des boîtes aux lettres :

Taille de boîte aux lettres = limite de boîte aux lettres + espace blanc + benne

Espace blanc = 100 messages par jour x 75/1024 Mo = 7,32 Mo

Benne = (100 messages par jour x 75/1024 Mo * 14 jours) + (2048 Mo x 0,012) + (2048 Mo x 0,03) = 188,6 Mo

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

Comme cet environnement exploite une architecture de stockage de type JBOD, la taille maximale de la base de données pouvant être déployée dépend de la taille du disque. Pour déterminer la taille maximale de la base de données pour le scénario JBOD, utilisez les formules suivantes, où la capacité d’un disque d’1 To formaté est de 931 Go, le pourcentage d’espace libre requis de 20 pour cent et le pourcentage de l’index de contenu de 10 pour cent :

taille maximum de la base de données = [capacité du disque formaté x (1 – pourcentage d’espace libre requis)] / (1 + pourcentage de l’index de contenu)

= [931 Go x (1 - 0,2)] / ( 1+ 0,10)

= 744,8 Go / 1,1

= 677 Go

Dans cet environnement, la boîte aux lettres de chaque utilisateur consomme 2,25 Go d’espace disque. Pour prendre en charge 24 000 boîtes aux lettres et une taille de base de données de 677 Go, il faut 102 bases de données. Cela donne un nombre final de 235 boîtes aux lettres par base de données.

Toutefois, comme cette solution exploite une architecture de stockage de type JBOD, il faut absolument s’assurer que le nombre de boîtes aux lettres par base de données ne dépasse la quantité d’E/S aléatoires pouvant être obtenues sur un seul disque. Comme cette solution fait appel à des piles de disques SATA 7,2K à grand facteur de forme, la pile peut atteindre jusqu’à 55 E/S aléatoires par seconde lorsqu’elle est utilisée à pleine capacité. En appliquant un facteur de croissance supplémentaire des E/S de 20 %, la pile peut donc traiter au total 44 E/S aléatoires par seconde.

Si la base de l’utilisateur possède un profil de 100 messages par jour, chaque boîte aux lettres devrait consommer 0,1 E/S par seconde ; par conséquent, le disque peut prendre charge jusqu’à 440 boîtes aux lettres avec ce profil d’E/S par seconde. Comme les calculs de capacité ont établi que le nombre maximal de boîtes aux lettres pouvant être prises en charge est égal à 235 et que ce nombre est en dessous du seuil des 440 boîtes aux lettres, déterminé sur la base du profil d’E/S par seconde, cette solution peut être déployée sur un seul disque.

Pour déterminer la taille réelle de la base de données, utilisez la formule suivante :

Taille de la base de données = Nombre de boîtes aux lettres x Taille des boîtes aux lettres sur le disque x Facteur de croissance supplémentaire de la base de données

En fonction du nombre de boîtes aux lettres, de leurs tailles réelles et du facteur de croissance de 20 %, la taille de la base de données est de 619 Go, comme le montre le tableau suivant.

Besoins en capacité des bases de données

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. Sous réserve que cette architecture exploite les fonctionnalités de résilience de boîte aux lettres et de récupération d’élément unique, la capacité des journaux doit couvrir trois fois le pourcentage de génération quotidienne de journaux au cas où la copie endommagée ne serait pas réparée pendant trois jours. (Toute copie endommagée empêche la troncature des journaux.)

Si une boîte aux lettres avec un profil de 100 messages par jour génère en moyenne 20 journaux de transactions par jour, un environnement de 24 000 boîtes aux lettres générera donc 576 000 journaux de transactions par jour. Cela signifie que chaque base de données générera 5 647 journaux par jour. Un pour cent des boîtes aux lettres sont déplacées par semaine sur un seul jour (le samedi). La solution utilise les fonctionnalités natives de protection des données d’Exchange et n’effectue donc pas de sauvegardes, et sa taille permet de tolérer trois jours sans troncature des journaux.

Comme indiqué dans le tableau suivant, ce serveur requiert 23 Go d’espace pour chaque copie de base de données.

Besoins en capacité des fichiers journaux

S’il s’agit d’une configuration Résilience de boîte aux lettres et JBOD avec trois copies, chaque base de données et ses journaux de transactions correspondants seront placés sur le même numéro d’unité logique (LUN). La taille LUN requise est la suivante :

Capacité du numéro d’unité logique = taille de la base de données ÷ (1 - pourcentage d’espace libre requis)

= (Taille de la base de données + taille du journal de transactions + taille de l’index de contenu) ÷ (1 - 0,2)

= (619 Go + 23 Go + 61,9 Go) / 0,8

= 879 Go

Détermination de la taille LUN requise

Retour au début

Configuration requise pour les copies de base de données

S’il faut au total 102 bases de données pour prendre en charge 24 000 boîtes aux lettres et si chaque base de données possède trois copies, le groupe de disponibilité de base de données prendra en charge 306 bases de données au total. Les 306 bases de données étant réparties sur six serveurs de boîtes aux lettres, chaque serveur de boîtes aux lettres héberge donc 51 copies de base de données. Les copies des bases des données doivent être réparties sur les serveurs du groupe de disponibilité de base de données de manière qu’une défaillance au niveau serveur entraîne un basculement des bases de données sur le plus grand nombre possible de serveurs restant disponibles (la distribution des bases de données n’est pas symétrique).

Pour optimiser l’efficacité des serveurs de boîtes aux lettres appartenant au groupe de disponibilité de base de données, les bases de données actives seront réparties de manière égale sur l’ensemble des serveurs de boîtes aux lettres. Par conséquent, lorsque les six serveurs de boîtes aux lettres fonctionnent chaque serveur doit normalement héberger 17 copies de bases de données actives.

En cas de défaillance d’un seul serveur de boîtes aux lettres, les 17 bases de données sont redistribuées sur les serveurs de boîtes aux lettres restants en augmentant le nombre de copies de bases de données actives par serveur pour le faire passer à 21.

En cas de défaillance de deux serveurs de boîtes aux lettres, les 34 bases de données sont redistribuées sur les serveurs de boîtes aux lettres restants en augmentant le nombre de copies de bases de données actives par serveur pour le faire passer à 26. Ce nombre de copies actives sera utilisé pour configurer la taille requise pour la mémoire et l’unité centrale du serveur de boîtes aux lettres.

Pour plus d’informations sur la distribution des copies de la base de données vers les serveurs de boîtes aux lettres, voir Conception de la disposition des copies de bases de données.

Retour au début

Besoins en mémoire des boîtes aux lettres

Avec un profil de 100 messages / jour, la capacité mémoire minimale par boîte aux lettres requise pour la mise en cache de la base de données est de 6 Mo. Si le nombre de bases de données de boîtes aux lettres actives est égal à 26 dans le pire des cas, chaque serveur doit héberger un nombre total de 6 110 boîtes aux lettres actives. En outre, le nombre total de bases de données par serveur est égal à 51. Le serveur de boîtes aux lettres requiert un cache de base de données minimal de 12 Go. Par conséquent, la quantité de mémoire requise pour prendre en charge le cache de base de données est calculée comme suit :

Taille minimale requise pour le cache de la base de données = MAX((Nombre de boîtes aux lettres actives x Capacité mémoire requise / boîte aux lettres), Capacité mémoire minimale pour les bases de données)

= MAX(6110 x 6/1024 Go, 12 Go)

= MAX (36 Go, 12 Go)

= 36 Go

Lors du déploiement d'une architecture multi-rôle, la capacité mémoire physique totale requise pour cette configuration est de 64 Go, selon le tableau dans Présentation du cache de la base de données de boîtes aux lettres.

Retour au début

Configuration E/S requise pour les boîtes aux lettres

Chaque boîte aux lettres envoie ou reçoit 100 messages par jour. Par conséquent, chaque boîte aux lettres a un profil d’E/S par seconde de 0,1 %. Chaque base de données héberge 235 boîtes aux lettres. Par conséquent, le nombre total d’E/S du volume de base de données est le suivant :

E/S du volume de base de données = Nombre de boîtes aux lettres x Profil d’E/S par seconde x (1 + Facteur de croissance supplémentaire des E/S)

= 235 x 0,1 x 1,2

= 28,2 E/S par seconde

Le pourcentage d’E/S de lecture par la base de données pour cette architecture est de 60 pour cent. Par conséquent, chaque volume de base de données génère 16,92 E/S de lecture par seconde et 11,28 E/S d’écriture par seconde.

Dans cette architecture, chaque flux de journal génère 50 % des E/S d’écriture dans la base de données. Par conséquent, les E/S d’écriture du journal par volume sont de 5,64 E/S par seconde.

Les 26 copies de bases de données actives génèrent également des E/S de lecture de journal représentant 10 % des E/S d’écriture de journal ; par conséquent les E/S de lecture de journal sont de 0,56 E/S par seconde.

Compte tenu que chaque disque SATA 7,2K à grand facteur de forme génère 55 E/S aléatoires par seconde, il ne fait aucun doute que le disque pourra répondre aux besoins en E/S de la base de données.

Retour au début

Besoins en processeur des boîtes aux lettres

Dans le cas de deux serveurs défaillants, les serveurs restants hébergent chacun 26 copies de base de données pour un total de 6 110 boîtes aux lettres actives par serveur. Selon les calculs établis dans la rubrique Planification des capacités du processeur du serveur de boîtes aux lettres, les besoins en mégacycles de chaque serveur sont les suivants.

Détermination des besoins en mégacycles

Si la plate-forme de serveurs choisie peut prendre en charge 26 400 mégacycles au total, la plate-forme UC de serveurs peut prendre en charge l’environnement en cas de défaillance de deux serveurs.

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.