Meilleures pratiques pour les dossiers publics Exchange : Évolutivité

Article
10/25/2013

Dernière rubrique modifiée : 2006-09-14

Lorsque vous créez et implémentez votre déploiement de dossiers publics Microsoft® Exchange Server, tenez compte des facteurs suivants au moment de déterminer l'optimisation de l'évolutivité :

Nombre de bases de données de dossiers publics
Largeur et profondeur de la hiérarchie de dossiers publics
Éléments par dossier public
Utilisateurs par base de données de dossiers publics

Cet article aborde chacun de ces facteurs en détail. Pour plus d'informations sur la taille du disque, les taux de croissance du dossier public et la planification de la capacité générale, voir Meilleures pratiques pour les dossiers publics Exchange : Gestion des données.

Nombre de bases de données de dossiers publics

Lorsque vous planifiez le nombre de bases de données de dossiers publics à déployer, tenez compte des deux pratiques suivantes.

Tout d'abord, pour les topologies de grandes entreprises, où les dossiers publics sont utilisés de façon intensive, déployez les serveurs de dossiers publics dédiés. Cette méthode provient de la pratique générale qui consiste à dédier des ressources d'UC et des ressources de disques aux fonctions de serveur isolées.

Ensuite, gardez à l'esprit que quelques bases de données de dossiers publics connaissent une amélioration de leur évolution et sont plus facilement gérées que des bases de données moins volumineuses. En réduisant le nombre de dossiers publics, vous pouvez diminuer le temps requis pour la sauvegarde et la restauration de nombreuses bases de données plus petites. Vous réduisez également la quantité de trafic de réplication en arrière-plan. En outre, la maintenance en ligne d'un nombre moins important de bases de données plus volumineuses est plus rapide que la maintenance de nombreuses bases de données moins volumineuses. Enfin, il est plus facile de gérer un plus petit nombre de bases de données de dossiers publics du point de vue de l'application d'autorisations et d'accès au contenu et de l'implémentation de réplications et de références efficace.

Le postulat selon lequel des bases de données volumineuses mais peu nombreuses évoluent mieux et se gèrent plus facilement que des bases de données nombreuses mais moins volumineuses est vrai si vous étudiez votre topologie au niveau de l'organisation. Au niveau du serveur, certaines tâches de gestion et de maintenance, telles que la sauvegarde et la restauration, sont effectuées plus rapidement lorsque des bases de données plus nombreuses et moins volumineuses sont déployées. Finalement, le nombre de bases de données de dossiers publics que vous déployez doit répondre aux besoins de votre entreprise. Lorsque vous déterminez le nombre de bases de données que vous souhaitez déployer, vous devez équilibrer le coût du trafic de réplication par rapport aux coûts de sauvegarde et de maintenance de la base de données et aux délais de restauration.

Largeur et profondeur de hiérarchie

Lorsque vous créez votre hiérarchie de dossiers publics, vous devez reconnaître l'effet de réplication de la hiérarchie dans votre environnement. Les hiérarchies de dossiers publics profondes évoluent plus rapidement que les hiérarchies larges. Une hiérarchie profonde se compose de plusieurs dossiers imbriqués verticalement au lieu de plusieurs dossiers de niveau supérieur. Une hiérarchie large se compose de plusieurs dossiers de niveau supérieur avec moins de sous-dossiers imbriqués verticalement.

Par exemple, imaginez la façon dont 250 dossiers peuvent être organisés dans une hiérarchie spécifique. Une hiérarchie large peut avoir 250 sous-dossiers directs sous un dossier parent. Une hiérarchie profonde peut comporter cinq dossiers de niveau supérieur, chacun étant composé de cinq sous-dossiers directs. Chacun de ces sous-dossiers peut contenir dix sous-dossiers.

Dans ces deux exemples, il y a 250 dossiers (5*5*10 = 250). Toutefois, la hiérarchie profonde offre de meilleures performances que la hiérarchie large et ce, pour deux raisons. La première raison est la façon dont la réplication gère les dossiers qui ont des autorisations différentes. La seconde raison réside dans les actions des clients, telles que le tri, la recherche, le développement, par rapport à un dossier qui contient dix sous-dossiers beaucoup moins coûteux qu'un dossier de 250 sous-dossiers.

Si les hiérarchies profondes évoluent mieux que les hiérarchies larges, il est néanmoins conseillé de ne pas dépasser le nombre de 250 sous-dossiers par dossier. Si le nombre de sous-dossiers est supérieur à 250, les opérations seront altérées lorsque le client demande l'accès.

Comme mentionné précédemment, vous devez tenir compte du fait que, lorsque vous implémentez une hiérarchie, les autorisations affectent les opérations du client lorsqu'il demande l'accès aux dossiers publics. Lorsque le sous-dossier de dossier public possède des entrées de liste de contrôle d'accès définies, chaque fois que l'ordinateur Exchange Server reçoit un nouveau message de réplication de dossier public, la liste de contrôle d'accès au dossier public parent doit être évaluée pour déterminer les utilisateurs qui ont le droit d'accéder aux modifications du dossier public parent. Si le dossier public parent a une grande entrée de liste de contrôle d'accès discrétionnaire, la mise à jour de l'affichage de chaque abonné de dossiers publics peut prendre du temps.

Remarque :
La liste de contrôle d'accès discrétionnaire (DACL) du dossier parent est constituée de la somme des listes DACL de tous les sous-dossiers de dossiers publics.

Vous pouvez avoir plusieurs mégaoctets (Mo) de données DACL qui doivent être distribués lorsque les conditions suivantes sont remplies :

Vous avez plusieurs sous-dossiers sous un dossier public parent unique.
Chacun de ces sous-dossiers a sa propre liste ACL définie.

Ces données DACL doivent être distribuées afin que l'affichage puisse être mis à jour pour tous les abonnés de dossiers publics à chaque réception d'un message de réplication de dossiers publics.

Par conséquent, il est conseillé d'organiser votre hiérarchie de dossiers publics en fonction des ensembles d'utilisateurs qui accèdent aux dossiers parents. En outre, n'implémentez pas les modèles d'autorisation complexes dans vos hiérarchies de dossiers publics. Si vous avez déjà implémenté une hiérarchie des dossiers approfondie avec diverses autorisations dans plusieurs nœuds de l'arborescence, voir l'article de la Base de connaissances Microsoft sur les utilisateurs qui sont confrontés à un temps de réponse lent lorsqu'ils accèdent à des dossiers publics sur un ordinateur exécutant Exchange Server 2003, dans lequel vous trouverez un correctif qui pourrait améliorer les performances du client. Pour un correctif similaire pour Exchange 2000 Server, voir l'article de la Base de connaissances Microsoft sur les utilisateurs qui sont confrontés à un temps de réponse lent du serveur de dossiers publics Exchange 2000 Server.

En ce qui concerne la conception de la hiérarchie, vous devez tenir compte de la façon de répliquer le contenu dans la hiérarchie. La plupart du temps, une distribution du contenu et une réduction du nombre de réplicas maximales sont justifiées. Pour plus d'informations, voir l'outil Meilleures pratiques pour les dossiers publics Exchange : Implémentation de la réplication.

Éléments par dossier

Il est conseillé que le nombre d'éléments ne dépasse pas 5 000 par dossier public. Pour gérer le nombre d'éléments par dossier, vous devez configurer l'expiration en conséquence. Si cette limite est régulièrement dépassée, même avec un délai serré, envisagez de segmenter l'objet de dossier public en sous-rubriques et de créer plusieurs dossiers publics pour chaque sous-rubrique.

Pour plus d'informations, voir l'outil Meilleures pratiques pour les dossiers publics Exchange : Gestion des données.

Utilisateurs par base de données de dossiers publics

Bien qu'il n'existe aucune limite du nombre d'utilisateurs qui peuvent avoir accès à une base de données de dossiers publics unique, il est recommandé de limiter le nombre d'utilisateurs à 10 000. La raison principale de la définition de cette limite vient du fait qu'Exchange Server risque de manquer de mémoire virtuelle de mémoire de noyau lorsque plus de 10 000 utilisateurs accèdent à une seule base de données.

Vous devez analyser Ouvertures de session client et Maximum d'ouvertures de session client dans l'objet de performances MSExchangeIS Public de l'outil d'administration du composant logiciel enfichable Performances dans la console Microsoft Management Console (MMC) pour effectuer le suivi du nombre d'utilisateurs qui ont accès aux dossiers publics sur un serveur donné.

Pour plus d'informations sur la surveillance de charge, le réglage et l'évolutivité des performances, reportez-vous à Exchange Server 2003 Performance and Scalability Guide.

Pour plus d'informations

Pour en savoir plus sur les dossiers publics dans Exchange Server, consultez les ressources suivantes :