Conception du stockage du serveur de transport

 

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

Dernière rubrique modifiée : 2009-01-26

Les serveurs de transport Hub et de transport Edge sont les rôles serveur qui remettent :

• les messages entrants et sortants de l'organisation ;

• les messages entrants et sortants des serveurs de boîtes aux lettres ;

• les messages vocaux soumis par des serveurs de messagerie unifiée.

Pour assurer une remise et un flux de messagerie efficaces au sein de votre organisation Exchange, les serveurs de transport Edge et de transport Hub doivent être associés à une solution de stockage correctement élaborée.

Cette rubrique fournit des informations et des exemples qui vous aident à déterminer les besoins en termes de capacité et d'entrées/sorties (E/S) pour les serveurs de transport Edge et de transport Hub.

Besoins en capacité et E/S des serveurs de transport Edge

Les serveurs de transport Edge doivent être conçus pour répondre aux besoins en termes de capacité et d'E/S transactionnelles de chaque organisation. Il est primordial de gérer correctement la croissance des files d'attente et de router les messages aussi rapidement que possible afin que les contrats de niveau de service (SLA) ne soient pas affectés. Plusieurs facteurs peuvent affecter la capacité globale d'un serveur de transport Edge :

• Journaux de suivi des messages

• Journaux de protocole

• base de données de boîtes aux lettres ;

• Journaux de connectivité

• Journaux de l'Agent

Il doit y avoir un minimum de 500 mégaoctets (Mo) d'espace libre et d'espace de base de données libre sur le lecteur contenant la base de données des files d'attente de messages. Dans le cas contraire, le système de transport active la contre-pression, une fonctionnalité de surveillance des ressources système du service de transport Microsoft Exchange Server 2007.

La valeur par défaut de la contre-pression est contrôlée par le paramètre PercentageDatabaseDiskSpaceUsedHighThreshold, qui peut être modifié le cas échéant. Pour plus d'informations sur la contre-pression et les options de configuration de cette fonctionnalité, consultez la rubrique Présentation de la fonctionnalité de régulation du flux.

Si les fichiers journaux de suivi des messages sont activés, une capacité supplémentaire est nécessaire. Les besoins en capacité de suivi des messages dépendent du nombre de messages reçus par le serveur de transport. Si votre organisation utilise Microsoft Exchange Server 2003, vous pouvez déterminer la fréquence actuelle de génération des journaux et définir une limite stricte du nombre de jours pendant lesquels les données sont conservées (par exemple, 10 jours). Microsoft génère 220 mégaoctets (Mo) pour les fichiers journaux de suivi des messages chaque jour ouvrable (moins pendant le week-end) et assure une capacité correspondant à une semaine de fichiers journaux (environ 1,3 Go). La taille des fichiers journaux de l'Agent, de connectivité et de protocole varie en fonction de l'activité. À titre de référence, les serveurs de transport de production installés chez Microsoft génèrent :

• de 5 à 15 Go pour les fichiers journaux de protocole par jour sur les serveurs de transport Edge. Une capacité suffisante pour le quota des fichiers journaux de protocole (15 Go) est assurée.

• 100 Mo pour les fichiers journaux de connectivité par jour sur les serveurs de transport Edge. Une capacité suffisante pour une semaine de fichiers journaux (environ 600 Mo) est assurée.

• 250 Mo pour les fichiers journaux de l'Agent par jour sur les serveurs de transport Edge. Une capacité suffisante pour une semaine de fichiers journaux (environ 1,5 Go) est assurée.

Les fichiers journaux des transactions ne requièrent pas beaucoup d'espace disque car la création de fichiers journaux normaux est limitée par l'utilisation de l'enregistrement circulaire. Les fichiers journaux des transactions peuvent donc être placés sur un numéro d'unité logique (LUN) contenant le système d'exploitation. Microsoft utilise un miroir à deux disques pour ce numéro d'unité logique.

La base de données (mail.que) ne stocke pas des éléments indéfiniment et la capacité réservée doit correspondre à la taille moyenne des messages multipliée par la file d'attente maximale, au cas où la file d'attente atteint sa capacité maximale alors que le serveur est arrêté. Une file d'attente de 500 000 éléments avec une taille moyenne de messages de 50 kilo-octets (Ko) correspond à environ 25 Go de données dans la base de données.

Les serveurs de transport Edge exécutant des analyses antivirus sur les messages entrants doivent avoir un espace suffisant pour la mise en quarantaine. Les besoins en ressources d'E/S de disque dépendent du pourcentage de messages entrants infectés par des virus (généralement peu élevé). La quantité de messages et pièces jointes infectés et leur durée de mise en quarantaine influe sur l'espace dévolu à la mise en quarantaine. Un espace disque de 1 Go est un bon point de départ, même si les besoins varient en fonction des organisations.

Pour la plupart des déploiements de serveur de transport Edge, il est recommandé d'ajouter un facteur de traitement correspondant à 20 % de la taille de la base de données (une fois tous les autres facteurs pris en compte). Cette valeur sera prise en compte pour les structures internes au sein de la base de données et assure un espace disponible suffisant si un pic ou des évolutions du flux de messagerie entraînent une croissance de la base de données.

Exemple de capacité pour un serveur de transport Edge

Dans cet exemple, les fichiers journaux des transactions sont stockés sur la partition du système d'exploitation (C:) hébergée par un contrôleur RAID (Redundant Array of Independent Disks) de mise en cache avec batterie de sauvegarde. Les besoins en capacité sont minimes (de l'ordre de quelques mégaoctets).

Le calcul de la capacité d'un serveur de transport Edge comporte deux étapes : Calculez tout d'abord la taille de la base de données, puis déterminez la taille du fichier journal des transactions.

Étape 1 : Taille de la base de données

Considérons un serveur de transport Edge recevant une moyenne de 5 messages par seconde (avec une taille moyenne de 50 Ko) sur une période de 24 heures, avec une file d'attente maximale de 500 000 éléments. Après l'ajout de tous les autres facteurs, un traitement supplémentaire de 20 % est ajouté et la taille totale sur le disque est de 58 Go, comme indiqué dans le tableau suivant.

Taille de base de données

File d'attente maximale	Capacité de la file d'attente	Journaux de protocole	Journaux de suivi des messages	Mise en quarantaine antivirus	Journaux de connectivité	Journaux de l'Agent	Espace libre	Taille totale sur le disque
500,000	Environ 25 Go (500 000 x 50 Ko)	15 Go	1,3 Go	1 Go	600 Mo	1,5 Go	4 Go	58 Go (48 G0 + 20 %)

Étape 2 : Taille du fichier journal des transactions

Pour déterminer la taille du fichier journal des transactions, vous devez prendre en compte les E/S transactionnelles, les autres E/S de disque et les E/S de base de données par seconde (ESPS) par message.

E/S transactionnelles

Si le serveur dispose d'une mémoire suffisante, les messages entrants sont stockés dans la RAM et dans le fichier journal des transactions, réduisant ainsi l'impact sur le disque. Lorsque les ressources de mémoire sont faibles, seuls les premiers 128 Ko d'un message sont stockés en mémoire et dans le fichier journal des transactions. Le reste du message est stocké dans la base de données. Au cours de la conversion du contenu, les données sont transférées vers un emplacement temporaire pour leur traitement. Cet emplacement est spécifié par le paramètre TemporaryStoragePath dans le fichier EdgeTransport.exe.config. Par défaut, la valeur du paramètre TemporaryStoragePath est définie sur « C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Temp ».

Il est essentiel de placer le répertoire temporaire sur le même numéro d'unité logique que la base de données. Il est également important de définir le cache du contrôleur de stockage sur 50 % en lecture et 50 % en écriture. Lorsque la file d'attente est peu importante, peu d'E/S de disque correspondent à des opérations de lecture. Lorsqu'une file d'attente existe, il se peut que le message ne soit pas dans le cache de la base de données, et un nombre d'E/S de disque plus élevé est requis.

Autres E/S de disque

Outre les E/S transactionnelles, il se peut que le système contienne d'autres E/S de disque. Par exemple :

• L'activation des fichiers journaux de suivi des messages requiert un traitement supplémentaire de 2 à 5 % des E/S de disque.

• L'activation des fichiers journaux de protocole et de connectivité implique un traitement léger des E/S de disque, qui dépend du nombre de messages entrants.

• L'activation des fichiers journaux de l'Agent par défaut implique un traitement léger des E/S de disque ; si des agents personnalisés sont utilisés, davantage de ressources de disque peuvent être nécessaires.

• Les opérations antivirus et de blocage du courrier indésirable se produisent dans la mémoire, requérant davantage de ressources de processeur.

Au cours du test, assurez-vous de tester vos serveurs de transport Edge avec tous les services en cours d'exécution qui seront utilisés en production.

ESPS de base de données par message

Au cours des tests internes menés à Microsoft, une taille moyenne des messages de 60 Ko était utilisée. De nombreuses organisations configurent leurs serveurs de transport avec une fréquence de messages spécifique, par exemple, 20 messages par seconde. Cette fréquence de messages requiert 140 E/S de base de données (20 × (4,5 + 2,5)) et 220 E/S de journal (20 × 11).

Lorsqu'une file d'attente se crée, plus de lectures sont requises, notamment dans le cas d'une partition RAID-1/0, car chaque disque physique répond aux demandes de lecture, comme indiqué dans le tableau suivant.

ESPS de base de données par message

E/S de base de données de transport Edge (état stabilisé)	E/S de transport Edge approximatives
ESPS total par message (environ 60 Ko)	18
E/S d'écriture de journal par message (séquentiel)	11
E/S d'écriture de base de données par message (aléatoire)	4.5
E/S de lecture de base de données par message (aléatoire)	2.5

Application des instructions de dimensionnement à votre conception matérielle pour un serveur de transport Edge

Une fois les besoins en termes de capacité et d'E/S transactionnelles définis pour un serveur de transport Edge, vous pouvez les appliquer à une conception matérielle proposée. Pour plus d'informations sur les configurations de la mémoire et du processeur, consultez les rubriques Planification des configurations de processeur et Planification des configurations de mémoire. Lors de la conception d'un serveur de transport Edge, il est important d'avoir une RAM suffisante (chaque message requiert 8 à 9 Ko de mémoire) dans le système pour empêcher la mise en cache temporaire des corps de message mis en file d'attente sur le disque.

Un serveur de transport Edge utilise une base de données ESE (Extensible Storage Engine). Afin d'optimiser la résilience et les performances, il est important d'isoler les fichiers journaux et de base de données sur leurs propres disques physiques dans les environnements dans lesquels la file d'attente sera importante. Dans les déploiements de moindre envergure avec des besoins en E/S de disque moindres, il est envisageable de placer les fichiers journaux des transactions et la base de données sur le même numéro d’unité logique. Le serveur de transport Edge, comme le serveur de boîtes aux lettres, requiert des temps de réponses d'E/S inférieurs à 20 millisecondes.

Il est important d'utiliser des contrôleurs RAID de mise en cache avec batterie de sauvegarde et d'exécuter la maintenance des bases de données de nuit. Veillez également à ce que le type de disque choisi assure un juste équilibre entre capacité et performances.

Exemple de dimensionnement de conception matérielle pour un serveur de transport Edge

Cet exemple présente la procédure de conception de votre stockage en fonction des messages attendus par seconde. Dans cet exemple, un serveur de transport Edge gère 20 messages par seconde, et requiert donc 140 ESPS pour le numéro d’unité logique de base de données et 220 ESPS pour le numéro d’unité logique de journal. Ajoutez toujours un facteur de croissance de 20 % pour les performances d'E/S de disque pour gérer les journées plus intenses. La partition de disque utilisée est RAID10. Pour les résultats de dimensionnement du matériel, consultez le tableau suivant.

Dimensionnement du matériel

Disques (1) et (2), partition RAID1	Disques (3), (4), (5) et (6), partition RAID10
Journaux du système d'exploitation et fichiers journaux : (220 + 20 %) = 264 ESPS	Fichiers journaux de base de données, de protocole et de suivi des messages et mise en quarantaine des virus : 140 + 20 % = 168 ESPS

Dans cet exemple, les besoins en capacité de numéro d'unité logique de base de données sont d'environ 70 Go pour une semaine de données. Vous devez doubler les besoins en capacité, soit 140 Go, pour deux semaines de données. L'utilisation de disques physiques de 146 Go permet d'obtenir un numéro d'unité logique de 292 Go dans une configuration RAID10.

Besoins en capacité et E/S des serveurs de transport Hub

Les serveurs de transport Hub doivent également être conçus pour répondre aux besoins en termes de capacité et d'E/S transactionnelles de l'organisation. Comme pour le serveur de transport Edge, il doit y avoir un minimum de 500 mégaoctets (Mo) d'espace libre et d'espace de base de données libre sur le lecteur contenant la base de données des files d'attente de messages. Dans le cas contraire, le système de transport active la contre-pression. Vous pouvez modifier la valeur par défaut du paramètre PercentageDatabaseDiskSpaceUsedHighThreshold sur les serveurs de transport Hub.

La capacité relative aux journaux de suivi des messages dépend du nombre de messages reçus par le serveur de transport. Si votre organisation utilise Microsoft Exchange 2003, vous pouvez déterminer la fréquence actuelle de génération des journaux et définir une limite stricte du nombre de jours pendant lesquels les données sont conservées (par exemple, 10 jours). Microsoft génère 700 mégaoctets (Mo) pour les fichiers journaux de suivi des messages chaque jour ouvrable (moins pendant le week-end) et assure une capacité correspondant à une semaine de fichiers journaux (soit environ 4,5 Go).

La taille des fichiers journaux de protocole varie en fonction de l'activité. Microsoft génère 2,7 Go de fichiers journaux de protocole par jour sur les serveurs de transport Hub et assure une capacité suffisante pour une semaine de fichiers journaux, soit environ 16 Go.

Les fichiers journaux des transactions ne requièrent pas beaucoup d'espace disque car la création de fichiers journaux normaux est limitée par l'utilisation de l'enregistrement circulaire. Les fichiers journaux des transactions peuvent donc être placés sur un numéro d'unité logique (LUN) du système d'exploitation. Microsoft utilise un miroir à deux disques pour ce numéro d'unité logique.

La base de données (mail.que) ne stocke pas des éléments indéfiniment et la capacité réservée doit correspondre à la taille moyenne des messages multipliée par la file d'attente maximale, au cas où la file d'attente atteint sa capacité maximale alors que le serveur est arrêté. Une file d'attente de 500 000 éléments avec une taille moyenne de messages de 50 Ko correspond à environ 25 Go de données dans la base de données.

Pour la plupart des déploiements de serveur de transport Hub, il est recommandé d'ajouter un traitement supplémentaire correspondant à 20 % de la taille de la base de données, une fois tous les autres facteurs pris en compte.

Conteneur de dépôt de transport

Il est important de prendre en considération les serveurs de transport Hub dans les sites contenant :

• des serveurs de boîtes aux lettres en cluster déployés dans un environnement de réplication continue en cluster (CCR) à l'aide d'Exchange Server 2007 RTM ou d'Exchange 2007 SP1 ;

• des serveurs de boîtes aux lettres exécutant Exchange 2007 (SP1) pour lesquels un ou plusieurs groupes de stockage sont activés pour la réplication continue locale (LCR).

Lors du déploiement d'un des environnements cités précédemment, assurez-vous de concevoir un serveur de transport Hub disposant d'une capacité de stockage des messages électroniques suffisante pour tous les groupes de stockage dans son site, afin que les messages soient récupérables en cas d'interruption non programmée du nœud actif. Cette fonctionnalité est appelée conteneur de dépôt de transport.

Le traitement des E/S par le conteneur de dépôt de transport revient à allonger une file d'attente. Deux paramètres permettent de contrôler la durée de conservation d'un message dans le conteneur de dépôt de transport : MaxDumpsterSizePerStorageGroup et MaxDumpsterTime. La valeur par défaut pour MaxDumpsterSizePerStorageGroup est 18 Mo. Pour dimensionner le conteneur de dépôt de transport correctement dans votre environnement, augmentez la taille de message acceptable la plus élevée de 50 %. Par exemple, si le quota de messages est de 10 Mo, vous devez définir le paramètre MaxDumpsterSizePerStorageGroup sur 15 Mo. Si plusieurs serveurs de transport Hub existent dans le même site de service d'annuaire Active Directory que le serveur de boîtes aux lettres en cluster dans l'environnement de CCR, ou dans un environnement de LCR exécutant Exchange 2007 SP1, le stockage global pour les groupes de stockage sur ce serveur de boîtes aux lettres en cluster est réparti sur tous les serveurs de transport Hub. Par exemple, si quatre serveurs de transport Hub ont un conteneur de dépôt de transport de 15 Mo, ce groupe de stockage aura un conteneur de dépôt de transport de 60 Mo.

Pour les organisations dans lesquelles aucune limite de taille de message n'est définie, il est recommandé de définir le paramètre MaxDumpsterSizePerStorageGroup sur une valeur équivalent à 1,5 fois la taille moyenne des messages envoyés dans l'organisation. En outre, si aucune taille maximale des messages n'est définie, vous ne pourrez peut-être pas récupérer ce message en cas de basculement non programmé dans un environnement de CCR ou après l'activation de la copie passive dans un environnement de LCR exécutant Exchange 2007 SP1

Il est recommandé de définir MaxDumpsterTime sur 7 jours, soit la valeur par défaut.

La capacité consommée par le conteneur de dépôt de transport doit correspondre au nombre de groupes de stockage multiplié par la taille maximale du conteneur de dépôt de transport. Si la taille maximale du conteneur de dépôt de transport est de 15 Mo et que le serveur de transport Hub dessert 100 groupes de stockage dans un environnement de LCR (Exchange 2007 SP1) ou de CCR (Exchange 2007 RTM), 1,5 Go doivent être alloués au conteneur de dépôt de transport.

Exemple de dimensionnement du conteneur de dépôt de transport

Dans cet exemple, les fichiers journaux des transactions sont situés sur le disque contenant la partition du système d'exploitation (C:) hébergée par un contrôleur RAID (Redundant Array of Independent Disks) de mise en cache avec batterie de sauvegarde. Les besoins en capacité seront minimes (de l'ordre de quelques mégaoctets). Pour les résultats de dimensionnement, consultez les tableaux suivants.

Le calcul de la capacité requise par le conteneur de dépôt de transport comporte deux étapes : Calculez tout d'abord la taille de la base de données, puis déterminez la taille du fichier journal des transactions.

Étape 1 : Taille de la base de données

Considérons un serveur de transport Hub recevant une moyenne de 5 messages par seconde sur une période de 24 heures, avec une file d'attente maximale de 500 000 éléments.

Dimensionnement du conteneur de dépôt de transport

File d'attente maximale	Capacité de la file d'attente	Journaux de protocole	Journaux de suivi des messages	Conteneur de dépôt de transport	Taille totale sur le disque
500,000	25 Go (500 000 × 50 Ko)	15 Go	4,5 Go	1,5 Go	55 Go (46 G0 + 20 %)

Étape 2 : Taille du fichier journal des transactions

Pour déterminer la taille du fichier journal des transactions, vous devez prendre en compte les E/S transactionnelles, les autres E/S de disque et les ESPS de base de données par message.

E/S transactionnelles

Les instructions ci-avant relatives aux E/S transactionnelles pour les serveurs de transport Edge s'appliquent également aux serveurs de transport Hub. Comme indiqué ci-avant, il est très important de configurer les paramètres du cache de votre contrôleur de stockage comme suit : 50 % en lecture, 50 % en écriture.

E/S du conteneur de dépôt de transport

Lorsque le conteneur de dépôt de transport est activé, les E/S de disque augmentent. Si les écritures de base de données augmentent, des lectures de base de données interviennent également sur les serveurs de production Microsoft, avec une moyenne de trois lectures par message.

Autres E/S de disque

Les instructions ci-avant relatives aux autres E/S de disque pour les serveurs de transport Edge s'appliquent également aux serveurs de transport Hub. Au cours du test, assurez-vous de tester vos serveurs de transport Hub avec tous les services en cours d'exécution qui seront utilisés en production.

ESPS de base de données par message

Au cours des tests internes menés à Microsoft, avec une taille moyenne des messages de 40 Ko, l'activation du conteneur de dépôt de transport requiert davantage de ressources de disque sur le serveur de transport Hub. De nombreuses organisations configurent leurs serveurs de transport avec une fréquence de messages spécifique, par exemple, 20 messages par seconde. Si le conteneur de dépôt de transport est activé, il requiert 200 E/S de base de données (20 × (7 + 3)) et 140 E/S de journal (20 × 7) pour prendre en charge une fréquence de messages entrants de 20 messages par seconde. Si le conteneur de dépôt de transport est désactivé, il requiert 40 E/S de base de données (20 × 2) et 40 E/S de journal (20 × 2) pour prendre en charge une fréquence de messages entrants de 20 messages par seconde.

Lorsqu'une file d'attente se crée, plus de lectures sont requises, notamment dans le cas d'une configuration RAID10, car chaque disque physique répond aux demandes de lecture. Pour plus d'informations, consultez le tableau suivant.

Dimensionnement du fichier journal des transactions

E/S de base de données de serveur de transport Hub (état stabilisé)	Conteneur de dépôt de transport activé	Conteneur de dépôt de transport désactivé
ESPS total par message (environ 40 Ko)	17	4
E/S d'écriture de journal par message (séquentiel)	7	2
E/S d'écriture de base de données par message (aléatoire)	7	2
E/S de lecture de base de données par message (aléatoire)	3	0

Application des instructions de dimensionnement à votre conception matérielle pour un serveur de transport Hub

Une fois les besoins en termes de capacité et d'E/S transactionnelles définis pour un serveur de transport Hub, vous pouvez les appliquer à une conception matérielle proposée. Pour plus d'informations sur la configuration de la mémoire et du processeur pour les serveurs de transport Hub, consultez les rubriques Planification des configurations de processeur et Planification des configurations de mémoire. Lors de la conception d'un serveur de transport Hub, il est important d'avoir une RAM suffisante (chaque message requiert 8 à 9 Ko de mémoire) dans le système pour empêcher la mise en cache temporaire des corps de message mis en file d'attente sur le disque.

Un serveur de transport Hub utilise une base de données ESE (Extensible Storage Engine). Afin d'optimiser la résilience et les performances, il est important d'isoler les fichiers journaux et de base de données sur leurs propres disques physiques dans les environnements dans lesquels la file d'attente sera importante ou lors de l'utilisation du conteneur de dépôt de transport. Dans les déploiements de moindre envergure avec des besoins en E/S de disque moins importants, il est envisageable de placer les fichiers journaux des transactions et la base de données sur le même numéro d’unité logique. Le serveur de transport Hub, comme le serveur de transport Edge, requiert des temps de réponses d'E/S inférieurs à 20 millisecondes.

Exemples de dimensionnement de conception matérielle pour un serveur de transport Hub

Il est important de concevoir votre stockage en fonction des messages attendus par seconde. Dans cet exemple, un serveur de transport Hub gère 20 messages par seconde, avec le conteneur de dépôt de transport désactivé, et requiert 40 ESPS pour le numéro d’unité logique de base de données et 40 ESPS pour le numéro d’unité logique de journal. Ajoutez toujours un facteur de croissance de 20 % pour les performances d'E/S de disque pour gérer les journées plus intenses. La partition de disque utilisée est RAID1. Dans cet exemple, les besoins en capacité de numéro d'unité logique de base de données sont d'environ 55 Go pour une semaine de données. Vous devez doubler les besoins en capacité, soit 110 Go, pour deux semaines de données. En utilisant des disques physiques de 140 Go, vous obtenez un numéro d'unité logique de base de données de 140 Go dans une configuration RAID1 et un numéro d'unité logique de journal de 140 Go dans une configuration RAID1. Pour les résultats, consultez le tableau suivant.

Dimensionnement matériel pour un serveur de transport Hub gérant 20 messages par seconde, avec le conteneur de transport de dépôt désactivé

Disques (1) et (2), partition RAID1	Disques (3) et (4), partition RAID1
Journaux du système d'exploitation et fichiers journaux : 40 + 20 % = 48 ESPS	Fichiers journaux de base de données, de protocole et de suivi des messages et mise en quarantaine des virus : 40 + 20 % = 48 ESPS

L'exemple suivant concerne un serveur de transport Hub gérant 20 messages par seconde, avec le conteneur de dépôt de transport activé. Cette configuration requiert 200 ESPS pour le numéro d'unité logique de base de données et 140 ESPS pour le numéro d'unité logique de journal, ainsi qu'un facteur de croissance de 20 %. La partition de disque utilisée est RAID10. Dans cet exemple, les besoins en capacité de numéro d'unité logique de base de données sont d'environ 55 Go pour une semaine de données, ou de 110 Go pour deux semaines de données. En utilisant des disques physiques de 140 Go, vous obtenez un numéro d'unité logique de base de données de 280 Go dans une configuration RAID10 et un numéro d'unité logique de journal de 140 Go dans une configuration RAID1.

Dimensionnement matériel pour un serveur de transport Hub gérant 20 messages par seconde, avec le conteneur de transport de dépôt activé

Disques (1) et (2), partition RAID1	Disques (3), (4), (5) et (6), partition RAID10
Journaux du système d'exploitation et fichiers journaux : 140 + 20 % = 168 ESPS	Fichiers journaux de base de données, de protocole et de suivi des messages et mise en quarantaine des virus : 200 + 20 % = 240 ESPS