Microsoft Exchange 5.5 : limites d'une banque d'informations illimitée
Peter Nilsson
Microsoft Consulting Services
Sur cette page
 | Vue d'ensemble |
| Introduction |
| Définition des limites |
| Nouvelle structure de planification |
| Des spécifications "sans risques" pour 2 000 utilisateurs ? |
| Planification et gestion de la capacité |
Vue d'ensemble
Point clé : impact sur la planification de la capacité d'une banque d'informations illimitée dans Microsoft Exchange Server 5.5.
Détails : moyen Tâche : développement, déploiement
|
Introduction
La limite matérielle de 16 Go par base de données qui existait dans Exchange 4.0 et 5.0 a disparu dans Microsoft Exchange Server 5.5, améliorant ainsi l'évolutivité de la banque d'informations. Le service Banque d'informations a été perfectionné, il est maintenant réparti sur 4 processeurs et utilise autant de RAM que vous pouvez en ajouter. Le moteur de stockage amélioré élimine les temps d'arrêt du serveur liés à la maintenance, et l'API de sauvegarde fonctionne avec le matériel de sauvegarde le plus rapide qui soit sur le marché des serveurs pour PC. Mais sommes-nous parvenus au point où nous pouvons moduler les serveurs Exchange indéfiniment ? Quel est l'impact de la banque d'informations illimitée (IS) — entendez par-là "stockage uniquement limité par le matériel" — sur la planification de la capacité ?
Définition des limites
Cette section traite des problèmes affectant les bases de données de banque d'informations et fournit des recommandations pour la définition de limites.
Limites "dures"
Tous les serveurs ont une configuration de matériel maximale. Cette configuration affecte la taille de la banque d'informations de deux manières :
| • | Taille de la partition physique : il s'agit de la taille maximale de la partition physique des données que vous pouvez configurer pour la base de données de banque d'informations. (Bien sûr, les fabricants de matériel continuent à se surpasser les uns les autres, repoussant toujours plus loin les frontières de la technologie des serveurs sur PC.) |
| • | Configuration maximale : les serveurs ont une configuration maximale en termes du nombre et des types de processeurs, de la quantité de RAM, etc. Il existe aussi des limites sur le nombre d'applications pouvant être exécutées sous Windows NT, généralement 2 Go (3 Go sous Windows NT/E) de mémoire maximale disponible pour les applications, ce qui affecte le nombre d'utilisateurs que vous pouvez placer sur un serveur. Nous expliquerons plus loin dans ce document pourquoi il faut également limiter l'espace alloué à chaque utilisateur, limitant ainsi la taille maximale de la banque d'informations à tout moment. |
Limites "souples" (opérationnelles)
Avec la banque d'informations illimitée d'Exchange 5.5, les administrateurs de réseau ont initialement l'intention d'optimiser l'utilisation des serveurs en ajoutant autant d'utilisateurs par serveur que possible. Cependant, les problèmes opérationnels liés au matériel peuvent être plus importants que l'obtention d'une certaine taille de banque d'informations. L'administrateur doit :
| • | définir des niveaux de risque acceptables pour les pannes de serveurs : les serveurs hors service laissent provisoirement les utilisateurs sans ressource. La gestion de ce risque pouvant coûter chère, l'administrateur doit savoir équilibrer la configuration des serveurs et le risque de perte de performances des utilisateurs pendant une panne inopinée ; |
| • | évaluer l'impact d'une sauvegarde en ligne sur les performances du système : bien que la sauvegarde en ligne d'Exchange ne doive pas affecter l'accès des utilisateurs, faites une estimation de la plage opérationnelle maximale de durée et de largeur de bande nécessaire pour une sauvegarde complète du système ; |
| • | calculer les performances de restauration des bases de données : sans perdre de vue que l'opération de restauration ne représente qu'une partie de la récupération d'un serveur, faites une estimation de la durée maximale acceptable pour la restauration d'une base de données. |
Nouvelle structure de planification
Cette section offre une structure permettant de planifier la banque d'informations de grands serveurs d'une façon cohérente que les administrateurs de système peuvent immédiatement prendre en charge. Elle ne traite cependant pas des questions d'optimisation des performances ou de planification de la capacité. Ces sujets seront abordés dans l'article Calcul du nombre d'utilisateurs par serveur et dans d'autres articles TechNet. Pour les administrateurs Exchange, la planification de la capacité est bien plus importante sur les très grands serveurs que sur les serveurs de taille moyenne qui étaient le plus souvent déployés par le passé. En voici la raison :
| • | Le coût d'une planification inadéquate pour 2 000 utilisateurs est bien plus élevé que le coût d'une planification inadéquate pour 500 utilisateurs. Par exemple, une partition RAID 5 devant contenir les bases de données de banque d'informations d'un serveur de taille moyenne peut comporter sept lecteurs de 4 Go, avec un débit nominal de 500 opérations d'E/S par seconde. Proportionnellement, il faudrait une partition RAID 5 de sept lecteurs de 18 Go pour 2 000 utilisateurs. Cette solution offre cependant un débit de 500 opérations d'E/S par seconde uniquement. Le sous-système de disques peut avoir un impact global plus important sur les performances du serveur de 2 000 utilisateurs, augmentant les risques d'engorgement pendant les heures de forte activité. |
| • | Bon nombre de serveurs Exchange 4.0 et 5.0 sont "surspécifiés". Les entreprises ont restreint le nombre d'utilisateurs par serveur, en faisant une estimation prudente d'après la taille limite de la banque à 16 Go. Par exemple, si vous allouez 50 Mo d'espace de stockage à chaque utilisateur, vous pouvez prendre en charge 320 utilisateurs par serveur avec 16 Go. Par expérience, les administrateurs peuvent prédire de façon sûre qu'un serveur sur un ordinateur Pentium Pro II avec 256 Mo de RAM et une configuration de disque appropriée (lecteur dédié aux journaux de transactions, partition des bases de données réparties sur 4 à 5 lecteurs) peuvent aisément traiter cette charge. Étant donné que les serveurs correspondant à ces spécifications sont offerts à des prix très compétitifs, un administrateur de banque d'informations peut facilement faire son choix sans trop de risques ni de recherche approfondie. |
Les critères permettant d'établir des spécifications de serveur sans risque ont cependant aujourd'hui disparu, ce qui oblige les administrateurs à spécifier le matériel requis pour prendre en charge un grand nombre d'utilisateurs avec de grandes banques d'informations. Il existe certaines directives présentées dans des livres blancs traitant des performances, publiés par Compaq, Digital et Hewlett Packard. Étant donné les paramètres relativement restreints même dans les meilleurs tests de performances, examinez attentivement ces résultats.
Des spécifications "sans risques" pour 2 000 utilisateurs ?
Pour les administrateurs souhaitant adopter une approche "sans risque", voici une ébauche pour un serveur de messagerie avec 2 000 utilisateurs, reposant sur l'expérience de Microsoft Consulting Services avec une entreprise ayant adopté Exchange 5.5 à ses débuts.
|
Cette configuration s'applique à un serveur de messagerie dédié. Tous les services supplémentaires que vous pouvez installer sur un serveur Exchange (service Événements, Outlook Web Access, IMS, divers connecteurs, etc.) ajoutent une charge significative et imprévisible sur le serveur. Comme il s'agit d'une configuration de service "sans risque", n'installez pas de services supplémentaires sur ce serveur de messagerie dédié.
Planification et gestion de la capacité
Contrôle de la taille de la banque d'informations
C'est en gardant le contrôle de la configuration que vous obtiendrez une prise en charge réseau Exchange efficace. Ceci est particulièrement important pour la gestion de la taille de la base de données Banque d'informations sur de grands serveurs. Rien ne compromettra votre capacité à maintenir un service de messagerie efficace et fiable aussi rapidement qu'une banque d'informations mal contrôlée. Lors de la planification du déploiement du serveur Exchange 5.5, spécifiez les points suivants :
1. | taille maximale de la banque d'informations pour la plate-forme matérielle ; |
2. | quota de l'espace de stockage alloué à chaque utilisateur afin de gérer la taille maximale de la banque d'informations ; |
3. | système de surveillance pour suivre la croissance de la taille de la banque ; |
4. | mesures à prendre au cas où la banque d'informations atteindrait sa taille maximale. |
Comme Exchange vous laisse une très grande flexibilité dans le choix des valeurs de stockage et des limites d'alerte réelles, créez une stratégie précise en ce qui concerne la banque d'informations et respectez-la. Si la taille de la banque d'informations est mal gérée, les risques qu'un des incidents graves mentionnés ci-dessous se produise augmentent.
| • | Il devient impossible de sauvegarder la base de données sur le périphérique de sauvegarde, vous finissez donc par ne plus avoir de sauvegarde à jour. |
| • | La restauration d'une sauvegarde prend beaucoup plus de temps que prévu, ce qui affecte le service de messagerie. |
| • | La base de données vient à manquer d'espace disque, ce qui entraîne l'arrêt du serveur Exchange. |
Taille maximale de la banque d'informations
Une équipe de planification Exchange va suivre plusieurs étapes pour planifier la capacité. Une fois que vous avez une idée de l'espace dont votre entreprise a besoin, établissez une stratégie détaillant les procédures de contrôle de la taille de la banque d'informations du serveur. Ce qui importe à ce stade, c'est de déterminer exactement la quantité de disque physique à allouer à la banque d'informations.
Pour gérer un espace de partition de façon efficace, il faut d'abord que tous les éléments qui résident sur cette partition soient bien organisés. Avec les serveurs Microsoft Exchange, dédiez une grande partition aux bases de données. Les journaux de transaction écrivant sur une pile dédiée (dans notre configuration de matériel "sans risque"), la partition des bases de données doit uniquement contenir des fichiers de base de données. Assurez-vous que les fichiers de base de données MTA et les autres fichiers de travail résident ailleurs, sur le disque système, par exemple.
Vous pouvez adopter deux approches pour limiter la taille de la banque d'informations.
1. | Gestion "de bonne foi" : définissez une marge de sécurité sur l'espace utilisé qui donne suffisamment de temps pour répondre (il est généralement conseillé de choisir 70 %). |
2. | Risques minimaux : définissez la taille maximale de la banque d'informations à 50% de l'espace disque disponible si vous pensez que vous risquez un jour de devoir effectuer une défragmentation hors ligne de la base de données Banques d'informations. |
Avec Exchange 5.5, vous n'avez pas besoin de programmer une défragmentation hors ligne (ESEUTIL /d). Cependant, si votre serveur nécessitait cette opération, vous auriez besoin de suffisamment d'espace libre pour la nouvelle base de données défragmentée. Cet espace ne doit pas nécessairement se trouver dans la même partition (ou sur le même serveur), mais en termes de fonctionnement, cela simplifie grandement la tâche.
Quotas par utilisateur
La définition de quotas pour l'espace de stockage alloué à chaque utilisateur simplifie grandement la gestion de la banque d'informations au sein d'une taille maximale. Bien qu'il ne s'agisse pas d'une science exacte, les quotas de taille vous permettent d'évaluer la taille maximale que peut atteindre la banque d'informations et d'empêcher les utilisateurs "abusifs" de la faire croître au-delà des limites que vous avez définies. Vous pouvez déduire la taille approximative de la banque d'informations d'après la taille moyenne des boîtes aux lettres et le rapport d'instance simple, à savoir le rapport approximatif de l'espace de stockage que les utilisateurs occuperont et de la taille physique de la banque d'informations. Pour un élément de messagerie moyen partagé par deux boîtes aux lettres, le rapport d'instance simple est de 2:1. En réalité, d'autres facteurs affectent la taille de la banque d'informations, tels que le nombre d'index, le niveau de fragmentation, etc., mais dans la pratique, les évaluations se révèlent remarquablement précises avec cette méthode de calcul :
((nombre d'utilisateurs) x (quota par utilisateur) x (% du quota utilisé)) / (rapport d'instance simple)
|
Il est bien sûr difficile d'évaluer le rapport d'instance simple sans données réelles. En pratique, le rapport est le plus souvent compris entre 1,25:1 et 2:1. On pourrait attendre de meilleurs rapports (dans la gamme 2:1) avec les banques d'informations plus grandes, puisque la probabilité que les messages et les pièces jointes soient partagés entre plusieurs utilisateurs est plus élevée sur les serveurs ayant un plus grand nombre d'utilisateurs.
Contrôle de la taille de la banque d'informations
Pour gérer la banque d'informations, il vous faut :
| • | effectuer le suivi de la croissance des banques d'informations, pour pouvoir calculer les besoins à venir ; |
| • | mettre en œuvre un système d'alerte déclenchant des événements lorsque la banque d'informations approche de sa taille maximale. (Vous pouvez utiliser l'Analyseur de performances de Windows NT ou tout autre logiciel de gestion pour déclencher une alerte lorsque l'espace disque libre descend en dessous d'un certain seuil.) |
Il est nécessaire d'interpréter les données d'occupation de l'espace, car la banque d'informations ne fournit pas d'informations exhaustives ni détaillées. Surveillez d'abord l'espace physique libre sur le disque. Bien qu'il s'agisse d'une valeur approximative, vous souhaitez gérer la taille de la banque du serveur Exchange. Surveillez la taille physique de chaque base de données. La taille de fichier quotidienne n'est pas représentative, car la taille du fichier de base de données Exchange s'actualise uniquement lorsque les services s'arrêtent.
Surveillez la quantité d'espace occupée par le cache des Éléments supprimés. Dans une banque établie dont la période de rétention est de une semaine maximum, la quantité d'espace utilisée devrait rester relativement faible. L'Analyseur de performances de Windows NT fournit des compteurs permettant de surveiller l'espace occupé, n'oubliez cependant pas que ces compteurs ne donnent qu'une indication et non une mesure précise de l'espace de stockage occupé.
Il vous faudra enfin déterminer la quantité d'espace disque libre au sein du fichier de base de données. La taille du fichier même représente la limite supérieure, en général, bon nombre d'éléments auront été supprimés et l'espace qu'ils occupaient sera récupéré par le service Banque d'informations. Bien qu'un fichier occupe 79% de l'espace disque, il pourrait y avoir à l'intérieur une grande quantité d'espace libre, limitant les risques d'augmentation à plus de 80 %. Exchange 5.5 Service Pack 1 ajoute un nouveau "commutateur de libération d'espace" à ESEUTIL (/ms) qui évalue la quantité d'espace qu'une défragmentation hors ligne permettrait de récupérer.
La défragmentation hors ligne est traitée dans la section Défragmentation ci-après.
Banques d'informations trop grandes
Lorsqu'une banque d'informations approche de la taille maximale définie, plusieurs solutions s'offrent à vous.
| • | Supprimez les anciens messages des boîtes aux lettres. Les utilisateurs apprécieront peu cette mesure radicale, notez toutefois que certaines entreprises effectuent déjà cette procédure de façon régulière. | ||||
| • | Ajoutez de l'espace disque supplémentaire à la partition de la base de données. Cette option n'est cependant pas sans risque.
| ||||
| • | Déplacez certains utilisateurs sur un autre serveur. En surveillant l'utilisation de l'espace sur tous les serveurs, vous saurez généralement où déplacer un groupe de boîtes aux lettres. Vous devriez rarement rencontrer de situation nécessitant la mise en œuvre d'un nouveau serveur. Cette option permet de conserver la stabilité du système, sans bouleverser la configuration du serveur, le modèle de fonctionnement ou la stratégie administrative. C'est pourquoi Microsoft Consulting Services recommande généralement cette option. |
Remarquez que dans un site Exchange, l'opération de déplacement d'utilisateurs essaie de conserver un stockage à instance simple. Faites cependant attention aux situations pour lesquelles l'instance simple entraîne la séparation de messages individuels.
Défragmentation
Exchange 4.0 et 5.0 effectuaient une routine d'entretien quotidienne qui consistait en une optimisation limitée des nombreux index conservés dans la banque, sans cependant récupérer d'espace libre dans la base de données de la banque d'informations. C'est pourquoi, bon nombre d'administrateurs avaient établi une défragmentation hors ligne (EDBUTIL /d) dans le cadre de leur programme de maintenance afin de récupérer de l'espace et d'optimiser les index. Microsoft déconseille d'effectuer régulièrement la défragmentation hors ligne d'une banque d'informations très grande, car cette procédure prend beaucoup de temps. L'équipe de développement des produits Exchange a amélioré le processus de défragmentation hors ligne qui s'effectue au cours de la maintenance quotidienne. Exchange 5.5 supprime la nécessité d'effectuer une défragmentation hors ligne pour des raisons de maintenance générale.
Vous devez uniquement effectuer une défragmentation hors ligne si vous avez besoin de diminuer la taille physique du fichier de base de données, par exemple après un événement majeur de fragmentation, tel que le déplacement d'un grand nombre de boîtes aux lettres (100 boîtes aux lettres, par exemple) à partir d'un serveur ou la suppression d'un grand nombre de groupes de discussion. Vous pouvez généralement éviter ce genre de scénario en gérant la banque d'informations dans les limites définies. Mettez cependant en place un plan d'urgence pour effectuer une défragmentation hors ligne. Comme stipulé dans la section Taille maximale de la banque d'informations, vous pouvez choisir entre deux approches, selon la manière dont vous évaluez les risques : réserver 50 % du disque physique sur chaque serveur Exchange ou réserver un certain espace sur le réseau pouvant être utilisé comme cible pour le processus de défragmentation.
Résistance et planification des désastres
Vous ne pourrez pas contourner ce fait essentiel : les serveurs de taille importante comportant un grand nombre d'utilisateurs concentrent les risques de panne de serveur sur un nombre de composants réduits. L'implémentation de grands serveurs Exchange 5.5 au sein d'une entreprise doit prendre ce problème en compte. Les administrateurs Exchange peuvent configurer la plupart des serveurs de haute qualité sur le marché à l'aide d'un éventail d'options fournissant une résistance. Ces options varient des sources d'alimentation ininterrompues à la protection RAID pour les disques, en passant par le duplexage des contrôleurs de disque, les NIC redondantes, etc. Vous pourrez peut-être mettre en place un serveur Exchange de façon à ce que le seul point de panne soit la carte mère.
Exchange 5.5 Édition Entreprise prend en charge la mise en clusters (Microsoft Cluster Server) qui offre une solution de basculement pour les composants tels que la carte mère. La prise en charge de la mise en clusters fonctionne très bien. Un basculement bien géré (qui implique l'arrêt propre d'un nœud) est exceptionnellement rapide (aussi rapide que l'arrêt et le démarrage des services Exchange sur un même nœud, mais sans le délai généralement causé par l'opérateur). Le basculement dû à une erreur peut être aussi rapide (si les services peuvent être arrêtés de façon propre sur le nœud en panne) ou légèrement plus lent s'il implique la relecture des journaux de transaction.
Avant de choisir de mettre en œuvre la mise en clusters, évaluez de façon très précise les possibilités que votre revendeur de matériel vous offre.
| • | Vous ne pourrez cependant pas éviter certaines défaillances de composants. Un cluster peut offrir une protection pour uniquement quelques composants de plus qu'un serveur autonome avec un jeu complet d'options de résistance, le risque de défaillance de ces composants est faible. Par exemple, le composant que vous souhaitez protéger, tel que le contrôleur d'ensemble de disques, pourrait encore être un point de défaillance unique partagé dans un cluster. |
| • | Les composants offrant un niveau de performances élevé à plusieurs milliers d'utilisateurs peuvent ne pas fonctionner dans des clusters. En raison de la façon dont MSCS a été développé (sous-systèmes de disques entraînés par des contrôleurs SCSI à deux initiateurs), bon nombre de contrôleurs d'ensemble de disques à haute performance, ainsi que d'autres périphériques avancés, peuvent ne pas être pris en charge. |
Les clusters présentent un avantage sur les systèmes autonomes, car ils sont capables de réduire au minimum les arrêts d'activité programmés en effectuant un basculement sur le nœud de veille afin d'effectuer les tâches de maintenance sur le nœud principal.
Le déploiement de grands serveurs Exchange 5.5 inclut également le développement d'un plan de récupération en cas de désastre. Dans le cas des situations de récupération (en espérant qu'elles soient peu nombreuses) requérant la restauration d'une banque d'informations depuis une bande (ou un autre support), assurez-vous que vous connaissez la durée de l'opération de restauration et que la procédure a été testée.
Performances de sauvegarde et de restauration
Bien que certains fabricants offrent du matériel de sauvegarde spécialisé, cette section traite d'une technique de sauvegarde classique à l'aide de contrôleurs et de périphériques principaux. À moins que l'entreprise ait des raisons ou des besoins spécifiques, il n'y a pas de raison d'abandonner les nombreux avantages qu'offre le matériel de base. Si vous avez vraiment besoin d'une solution particulière, telle que la mise en miroir de disque pour les très grands serveurs, examinez les problèmes potentiels ci-dessous.
| • | Certaines solutions impliquent d'arrêter les services Exchange, même pour une courte durée, pour faire une copie hors ligne de la base de données de la banque d'informations. Elles requièrent donc de gérer les interruptions de service régulières. |
| • | Les sauvegardes hors ligne copient uniquement les secteurs de disque. La sauvegarde hors ligne d'Exchange implique la lecture de toutes les pages de base de données via une API, examinant le total de contrôle de chaque page pour détecter les corruptions qui ne l'ont pas été par d'autres méthodes. Quel que soit le type de sauvegarde et de récupération mis en œuvre, effectuez des sauvegardes en ligne régulièrement. |
Les solutions standard offrent des performances impressionnantes, avant de vous investir dans l'examen de solutions matérielles spécialisées, considérez les points suivants :
| • | options d'amélioration des performances des solutions standard, telles que la prise en charge RAID sur bande ; |
| • | scénarios de restauration, car les performances de restauration sont plus importantes que les performances de sauvegarde. |
Le périphérique "rapide" sur les serveurs haute performances d'aujourd'hui est le DLT 35/70. C'est en équilibrant le débit du périphérique de lecture et celui du périphérique d'écriture que vous obtiendrez une vitesse de sauvegarde élevée. Le périphérique DLT 35/70 peut lire plusieurs disques standard à 7 200 rpm en parallèle tout en écrivant sur un disque DLT 35/70 unique à la vitesse maximale. Ceci est particulièrement approprié, puisqu'une partition de disque se répartit sur plusieurs disques, prenant en charge une grande base de données de banque d'informations.
Si une partition de disque se répartit sur plus de 7 disques (par exemple), vous pouvez obtenir des vitesses de sauvegarde encore plus élevées en écrivant sur plusieurs disques DLT en parallèle. Cela nécessite un logiciel de sauvegarde, tel que les options RAID pour les périphériques à bande, capable d'associer plusieurs lecteurs de bande dans une seule partition logique sur une partition RAID de disque. Microsoft Consulting Services a travaillé en collaboration avec des entreprises ayant atteint des vitesses de sauvegarde de 30 Go/heure depuis 7 disques vers un seul périphérique DLT 35/70 (utilisant ARCserve) et de 40 Go/heure depuis 13 disques vers un ensemble de 4 périphériques DLT 35/70 configurés en tant qu'ensemble RAID 5 (utilisant aussi ARCserve).
Les vitesses de restauration ne sont malheureusement pas aussi impressionnantes que les vitesses de sauvegarde. La majorité des contrôleurs d'ensemble de disques ne sont pas optimisés pour la restauration en bloc et l'écriture des données de parité RAID 5 sur les disques réduit les vitesses de restauration. Les configurations permettant d'atteindre des vitesses de sauvegarde de 30 et 40 Go/heure permettent seulement d'atteindre des vitesses de restauration de 16 et 20 Go/heure respectivement. Vous pouvez vous attendre à de meilleures performances sans RAID 5, mais cette discussion s'est axée sur les sous-systèmes RAID 5 car ils sont universellement mis en œuvre dans les partitions de base de données Exchange. Testez et étudiez les vitesses de restauration de vos serveurs en planifiant la durée totale de restauration des bases de données Exchange et la croissance des banques d'informations.
Dernière mise à jour le jeudi 19 octobre 2000