Présentation des facteurs de capacité des journaux et des bases de données de boîtes aux lettres
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2015-03-09
Cette rubrique explique les facteurs dont vous devriez tenir compte lorsque vous planifiez la capacité des bases de données de boîtes aux lettres et des journaux lors de la conception de votre solution de stockage de serveur de boîtes aux lettres dans Microsoft Exchange Server 2010.
Capacité des bases de données de boîtes aux lettres
De nombreux facteurs influencent un plan de détermination de la capacité des bases de données de boîtes aux lettres Exchange Server 2010. Cette section traite des sujets suivants :
Quotas de stockage de boîte aux lettres
Espaces blancs dans la base de données
Éléments récupérables d’une base de données de boîtes aux lettres
Taille réelle de la boîte aux lettres
Indexation de contenu
Maintenance de base de données en mode hors connexion
Base de données de récupération
Taille de la base de données
Capacité supplémentaire pour l’augmentation de la taille de la base de données
Quotas de stockage de boîte aux lettres
La première mesure que vous devez comprendre est la limite de taille de stockage (également appelée quota de stockage de boîte aux lettres) en vigueur dans votre organisation. Si vous connaissez la quantité de données qu’un utilisateur final est autorisé à stocker dans sa boîte aux lettres, vous pouvez déterminer le nombre de boîtes aux lettres utilisateur pouvant être hébergées sur le serveur. Bien que les quotas de stockage de boîte aux lettres puissent changer en raison de l’évolution des impératifs de l’organisation, lorsque vous déterminez la capacité nécessaire aux bases de données de boîtes aux lettres, la première étape consiste à définir un objectif en termes de quota de stockage.
Par exemple, si vous disposez d’un serveur hébergeant 5 000 boîtes aux lettres utilisateur de 250 Mo, vous avez besoin d’au moins 1,25 To (téraoctets) d’espace disque, outre l’espace requis pour les éléments récupérables. Si aucune limite n'est définie pour les quotas de stockage de boîte aux lettres, vous constatez qu'il est difficile d'estimer la capacité de la base de données. Les quotas de stockage de boîte aux lettres pour Exchange 2010 doivent inclure l’espace requis pour la boîte aux lettres principale et la boîte aux lettres d’archivage personnelle (lorsqu’elle est utilisée). Pour plus d’informations, consultez les rubriques Gestion des serveurs de boîtes aux lettres et Gestion de l’archive personnelle.
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 de stockage de la boîte aux lettres. Lorsque la plupart des utilisateurs n'atteignent pas le quota de stockage de leur boîte aux lettres, les bases de données consomment moins d'espace, et les espaces blancs ne constituent pas une préoccupation en termes de capacité. La base de données proprement dite comporte toujours des pages blanches ou des espaces blancs. Lors de la maintenance de la base de données en arrière-plan, les éléments marqués pour suppression sont supprimés de la base de données et libèrent ces pages. Le pourcentage d’espaces blancs est en constante évolution en raison des efforts du processus de défragmentation en ligne 24h/24 et 7j/7.
Vous pouvez estimer la quantité d’espaces blancs d’une base de données si vous connaissez la quantité de messages envoyés et reçus par les utilisateurs possédant des boîtes aux lettres dans celle-ci. Par exemple, si disposez d’une base de données incluant cent boîtes aux lettres de 2 Go (totalisant 200 Go) et que les utilisateurs échangent en moyenne 10 Mo de messages par jour, la quantité d’espaces blancs est égale à 1 Go environ (100 boîtes aux lettres x 10 Mo par boîte aux lettres). La quantité d'espaces blancs peut être supérieure à cette valeur approximative si la maintenance de la base de données en arrière-plan ne peut pas être effectuée complètement.
Retour au début
Éléments récupérables d’une base de données de boîtes aux lettres
Chaque base de données dispose d’un conteneur de dépôt stockant les éléments supprimés récupérables. Par défaut, les éléments supprimés récupérables sont stockés pendant 14 jours, et les éléments de calendrier sont stockés pendant 120 jours dans Exchange 2010.
En outre, Exchange 2010 permet d’empêcher la purge des données avant que la période de rétention des éléments supprimés ait expiré. Cette fonctionnalité est appelée récupération d’élément unique. La récupération d’élément unique est désactivée par défaut. Toutefois, lorsque la récupération d’élément unique est activée, la taille de la boîte aux lettres augmente de 1,2 pour cent pour une période de rétention des éléments supprimés de 14 jours. Dans le cas des données de journalisation de version du calendrier, la taille de la boîte aux lettres augmente de 3 pour cent. Les données de journalisation de version du calendrier sont activées par défaut.
La formule permettant de déterminer la quantité d’espace disque requise pour le conteneur de dépôt sur une période de rétention des éléments supprimés de 14 jours lorsque la journalisation de la version du calendrier et la récupération d’élément unique sont activées est la suivante :
Taille du conteneur de dépôt = (courrier entrant/sortant quotidien X taille moyenne des messages X période de rétention des éléments supprimés) + (taille du quota de la boîte aux lettres X 0,012) + (taille du quota de la boîte aux lettres x 0,03)
Par exemple, si la taille de la boîte aux lettres est 2 Go, l’activation de la récupération d’élément unique sur une période de rétention des éléments supprimés de 14 jours nécessite 25 Mo d’espace supplémentaire, et la fonctionnalité de journalisation du calendrier nécessite 61 Mo d’espace supplémentaire.
Pour plus d’informations, consultez les rubriques suivantes :
Taille réelle de la boîte aux lettres
Au bout d’un certain temps, le quota de stockage de la boîte aux lettres de l’utilisateur est atteint. Par conséquent, une quantité de messages égale à la quantité de courrier entrant doit être supprimée afin que la valeur de quota de stockage de la boîte aux lettres ne soit pas dépassée. En raison de cet impératif, la taille du conteneur de dépôt augmente jusqu’à une taille maximale correspondant à la quantité de messages envoyés et reçus quotidiennement multipliée par le nombre de jours de la période de rétention des éléments supprimés. Si la valeur de quota de stockage n'a pas été atteinte pour la plupart des utilisateurs, seule une partie du courrier entrant/sortant est supprimée. Par conséquent, la croissance est répartie entre le conteneur de dépôt et l’augmentation de la taille de la boîte aux lettres.
Pour déterminer la taille de la base de données à l’aide d’une boîte aux lettres de 2 Go sans recourir à la fonctionnalité d’archive personnelle, consultez la section « Besoins en capacité de la boîte aux lettres » dans la rubrique Exemple de conception d'un rôle serveur de boîtes aux lettres Exchange 2010.
Une fois que vous avez déterminé l’estimation de la taille réelle de la boîte aux lettres, vous pouvez utiliser cette valeur pour déterminer le nombre maximal d’utilisateurs par base de données. Divisez la taille prévue de la boîte aux lettres par la taille recommandée de la base de données. Cette valeur vous permettra également de déterminer le nombre de bases de données dont vous aurez besoin pour gérer le nombre d’utilisateurs prévu, en partant du principe 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, vous devrez peut-être 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 opérations de sauvegarde et de restauration, bien que la gestion soit plus complexe en raison d’un nombre élevé de bases de données par serveur.
Indexation de contenu
L’indexation de contenu crée un index (catalogue) qui permet aux utilisateurs de procéder à des recherches simples et rapides parmi leurs éléments de courrier, au lieu d’effectuer des recherches manuelles dans la boîte aux lettres. Exchange 2010 crée un index correspondant à environ 10 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. Par conséquent, une capacité supplémentaire de 10 pour cent doit être prise en compte dans la taille du numéro d’unité logique de la base de données pour l’indexation de contenu.
Retour au début
Maintenance de base de données en mode hors connexion
La capacité d’une base de données devant être compressée en mode hors connexion doit être égale à la taille de la base de données cible plus 10 pour cent. Si vous attribuez suffisamment d’espace pour une seule base de données ou un jeu de sauvegarde, de l’espace supplémentaire doit être disponible pour réaliser ces opérations.
.gif "Important") Important : |
|---|
| Les procédures de maintenance en mode hors connexion doivent être réalisées à la demande du support technique de Microsoft, car elles rendent non valides toutes les copies de base de données et nécessitent un réamorçage complet de la base de données. |
Base de données de récupération
Si vous prévoyez d’utiliser une base de données 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 qui devront être restaurées simultanément sur ce serveur. Pour plus d’informations, voir Récupérer des bases de données.
Taille de la base de données
C’est la taille de base de données qui détermine au final le nombre de boîtes aux lettres déployées dans chaque base de données, ainsi que le nombre de bases de données déployées. La taille de base de données que vous déployez dépend de plusieurs facteurs :
Contrats de niveau de service (SLA) de sauvegarde/restauration La taille de base de données définit au final la vitesse de sauvegarde et de restauration des données dans un laps de temps raisonnable.
Architecture à haute disponibilité Si vous prévoyez d’utiliser plusieurs copies de bases de données, vous pouvez définir une taille de 2 To pour vos bases de données, car vos copies constituent votre première ligne de défense en termes d’opérations de récupération.
Architecture de stockage Si vous prévoyez de procéder au déploiement sur un système de stockage JBOD (un disque héberge la base de données ainsi que les journaux de transactions correspondants), la taille du disque que vous utilisez détermine la taille de base de données maximale. Par exemple, sur un disque de 1 To (avec une capacité d'environ 917 Go une fois le disque formaté), vous devez inclure de l'espace pour les journaux de transactions et l'index de contenu. Vous devez également veiller à ce que l'espace disponible ne soit pas entièrement consommé.
Capacité supplémentaire pour l’augmentation de la taille de la base de données
Une fois tous les facteurs pris en compte et calculés, nous vous conseillons d’inclure un facteur de capacité supplémentaire de 20 pour cent pour le numéro d’unité logique de la base de données. 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 de la taille des boîtes aux lettres et des espaces blancs.
Retour au début
Capacité des journaux
Les fichiers journaux de transactions constituent un enregistrement de chaque transaction effectuée par le moteur de base de données. Toutes les transactions sont d’abord écrites dans le journal, puis dans la base de données. Par rapport à Exchange Server 2003, la taille des fichiers journaux de transactions dans Exchange 2010 est passée de 5 Mo à 1 Mo. Cette modification a été apportée pour prendre en charge les fonctions de réplication continue et pour réduire le volume de perte de données en cas de défaillance du stockage principal.
Vous pouvez utiliser le tableau suivant pour estimer le nombre de journaux de transactions générés sur un serveur de boîtes aux lettres Exchange 2010 sur lequel la taille moyenne des messages est de 75 Ko.
La valeur définie pour le Nombre de journaux de transactions générés quotidiennement est basée sur le profil de message sélectionné et sur la taille moyenne du message. Elle indique combien de journaux de transactions seront générés quotidiennement par boîte aux lettres. Les numéros de génération de journal par profil de message tiennent compte des éléments suivants :
Impact sur la taille du message
Quantité de données envoyées/reçues
Opérations de maintenance de l’intégrité de la base de données
Opérations de gestion des enregistrements
Données stockées dans une boîte aux lettres sous une forme autre qu’un message (tâches, rendez-vous locaux sur le calendrier, contacts)
Substitution de journal forcée (mécanisme qui ferme régulièrement le fichier journal des transactions actif)
Nombre de journaux de transactions générés par profil de boîte aux lettres
| Profil de message (taille moyenne des messages de 75 Ko) | Nombre de journaux de transactions générés par jour |
|---|---|
50 |
10 |
100 |
20 |
150 |
30 |
200 |
40 |
250 |
50 |
300 |
60 |
350 |
70 |
400 |
80 |
450 |
90 |
500 |
100 |
Vous pouvez utiliser les instructions suivantes pour comprendre l’incidence de la taille des messages sur la fréquence de génération des journaux de transactions :
Si la taille moyenne des messages est multipliée par deux et atteint 150 Ko, les journaux générés par boîte aux lettres augmentent d’un facteur de 1,9. Cette valeur représente le pourcentage de la base de données contenant les tables des messages et pièces jointes (corps des messages et pièces jointes).
Par la suite, lorsque la taille des messages est multipliée par deux et dépasse 150 Ko, la fréquence de génération des journaux est également multipliée par deux : elle passe de 1,9 à 3,8.
Par exemple, si vous avez un profil de 100 messages par jour et :
une taille moyenne de message de 150 Ko, le nombre de journaux générés par boîte aux lettres est le suivant : 20 × 1,9 = 38 ;
une taille moyenne de message de 300 Ko, le nombre de journaux générés par boîte aux lettres est le suivant : 20 × 3,8 = 76.
Les sections suivantes décrivent les facteurs qui ont une incidence sur la capacité des journaux :
Facteurs liés à la sauvegarde et à la restauration
Opérations de déplacement de boîte aux lettres
Facteur de capacité supplémentaire pour l’augmentation de la taille du fichier journal
Facteurs liés à la haute disponibilité
Planification de la capacité du numéro d’unité logique
Facteurs liés à la sauvegarde et à la restauration
La détermination de la taille du numéro d’unité logique du journal dépend en partie de la conception de votre méthode de sauvegarde et de restauration. Par exemple, si votre méthode 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 méthode de sauvegarde inclut des sauvegardes hebdomadaires complètes et des sauvegardes quotidiennes différentielles, le numéro d’unité logique du 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. La plupart des entreprises effectuant une sauvegarde complète nocturne attribuent une valeur correspondant à deux ou trois fois la capacité de génération de journaux quotidiens. Elles adoptent cette approche pour éviter que l’échec d’une sauvegarde ne provoque la saturation du lecteur des journaux, ce qui entraînerait le démontage de la base de données.
Si vous envisagez d’utiliser les fonctionnalités de résilience de boîte aux lettres et de récupération d’élément unique d’Exchange 2010 comme infrastructure de sauvegarde (et donc d’activer l’enregistrement circulaire), il est recommandé d’attribuer une valeur correspondant à trois fois la capacité de génération de journaux quotidiens nécessaire. De cette manière, lorsque la réplication est suspendue ou ne fonctionne pas avec des paramètres normaux, vous êtes certain que les bases de données ne sont pas démontées en raison d'échecs de troncature.
Opérations de déplacement de boîte aux lettres
Le déplacement de boîtes aux lettres est un facteur de capacité essentiel pour les déploiements de boîtes aux lettres de grande envergure. Bon nombre de grandes entreprises déplacent un pourcentage de leurs boîtes aux lettres utilisateur chaque nuit ou chaque semaine vers d’autres bases de données, serveurs ou sites. Si votre organisation procède de cette manière, vous devrez peut-être affecter des capacités supplémentaires au numéro d’unité logique du journal pour faciliter les déplacements de boîtes aux lettres.
Bien que le serveur source enregistre les suppressions d’enregistrements, qui sont de faible taille, le serveur cible doit d’abord écrire toutes les données transférées dans les journaux de 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 le numéro d’unité logique de journal cible et provoque un temps d’arrêt. Dans de tels cas, vous devrez probablement affecter des capacités supplémentaires aux numéros d’unité logique de journal pour gérer les déplacements de vos boîtes aux lettres.
Facteur de capacité supplémentaire pour l’augmentation de la taille du fichier journal
Dans la plupart des déploiements, il est recommandé d’ajouter un facteur de capacité supplémentaire de 20 pour cent à la taille du journal (une fois tous les autres facteurs pris en compte) lors de la création du numéro d’unité logique du journal pour bénéficier d’une capacité suffisante en cas de génération de journaux imprévue.
Facteurs liés à la haute disponibilité
La haute disponibilité influe de trois manières importantes sur les exigences en termes de capacité des journaux :
Nombre de copies de base de données La capacité de journal de l’ensemble du système augmente en fonction du nombre de copies de base de données choisi dans le déploiement à haute disponibilité. Si vous disposez de trois copies de base de données réparties sur trois serveurs, vous devez configurer la capacité de journal pour chaque copie sur chaque serveur.
Mécanisme de troncature de journaux La haute disponibilité d’Exchange 2010, associée à la possibilité de gérer jusqu’à 16 copies de chaque base de données de boîtes aux lettres, constitue la base de l’utilisation de l’enregistrement circulaire avec réplication continue comme mécanisme de troncature/suppression de journal, au lieu d’exécuter des sauvegardes complètes/incrémentielles pour tronquer ou supprimer les journaux anciens. Pour plus d’informations, voir la section relative à la troncature de journaux sans sauvegarde dans les rubriques Présentation de la sauvegarde, de la restauration et de la récupération d'urgence et Haute disponibilité et résilience de site.
Retard de relecture des copies de base de données La haute disponibilité dans Exchange 2010 offre la possibilité de retarder la relecture des journaux des copies de base de données passives (configurée pour chaque copie). Cette fonction permet de fournir un délai lorsque les journaux sont lus dans des copies de base de données retardées. Ce délai peut être utile pour vous protéger contre des événements qui entraîneraient la réplication du contenu indésirable vers toutes les copies de base de données. Il est possible d’interdire la lecture du contenu dans la copie de base de données retardée en suspendant la relecture avant que les journaux incluant le contenu indésirable soient lus dans la base de données.
Lorsque le retard de relecture est activé pour une copie de base de données, les exigences en termes de capacité des journaux sont modifiées en conséquence. Si le délai de retard a la valeur 14 jours, vous devez définir une valeur équivalant à 17 jours de journaux. La capacité supplémentaire pour les journaux est requise uniquement pour la copie de base de données pour laquelle le retard est configuré ; pour les autres copies de cette base de données sans retard défini, les exigences en termes de capacité des journaux sont normales (pas de retard).
Pour plus d’informations, voir Présentation des facteurs de haute disponibilité.
Planification de la capacité du numéro d’unité logique
Les exigences en termes de capacité du numéro d’unité logique reposent sur la taille du jeu de données (base de données, journaux de transactions, index de contenu et espace de récupération) et de l’espace libre supplémentaire. Dans la plupart des programmes de gestion des opérations, les seuils de capacité génèrent une alerte lorsque le taux d’utilisation d’un numéro d’unité logique excède 80 pour cent.
La formule suivante vous permet de déterminer la taille appropriée du numéro d’unité logique :
Capacité du numéro d’unité logique = taille des données / (1 - pourcentage d’espace libre requis)
Par exemple, si vous avez besoin de 3 000 Mo pour les données et d’un pourcentage d’espace libre de 20 pour cent, la taille du numéro d’unité logique hébergeant ces données doit être de 3 750 Mo.
Prévention de la consommation totale de l'espace de disque pour journaux de transactions
Pour éviter de consommer tout votre espace de disque pour journaux de transactions, vous devez commencer par calculer une ligne de base de votre environnement afin de déterminer le taux journalier typique de génération de journaux. Vous devez ensuite configurer la surveillance et prendre des mesures concernant toute alerte générée. Vous devez surveiller les éléments suivants :
Espace de disque Log LUN pour transactions. Configuration de plusieurs seuils et de différents mécanismes d'alerte. Par exemple, si vous connaissez votre ligne de base de génération de journaux typique, vous pouvez configurer un seuil dont le dépassement de 20 pour cent entraînera la sortie d'un rapport.
Sauvegardes correctes (si vous ne profitez pas de la protection des données natives Exchange).
Troncature des événements dans le journal des applications.
Intégrité de la réplication de la copie de votre base de données.
Résolution des problèmes de croissance inexpliqués dans les journaux de transactions
Pour aider à remédier à la croissance inexpliquée dans les journaux des transactions, voir Gérer la croissance des journaux des bases de données à l’aide du script Troubleshoot-DatabaseSpace.ps1 dans l’environnement de ligne de commande Exchange Management Shell.
© 2010 Microsoft Corporation. Tous droits réservés.