Présentation des configurations de rôle serveur multiples dans la planification des capacités
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2016-11-28
Plusieurs tendances de configuration matérielle des serveurs s’appliquent à la période de Microsoft Exchange Server 2010. Une première tendance est l’augmentation significative des performances des processeurs et le nombre croissant de cœurs de processeur pris en charge par un seul processeur physique. Par conséquent, le déploiement d’un seul rôle serveur Exchange sur un serveur standard équipé de processeurs multicœur pourrait entraîner une sous-exploitation des ressources processeur disponibles. Certains clients pensent que la virtualisation des serveurs exploitera plus efficacement les ressources processeur du serveur. D’autres clients souhaitent combiner des rôles de serveur Exchange sur le même serveur physique. Les deux sont des solutions valides.
Une deuxième tendance est la disponibilité de modèles de serveur composés de processeurs multicœur et de 10 à 16 disques internes. Si vous tenez compte du nombre de boîtes aux lettres pouvant être prises en charge par le nombre d’entrées/sorties par seconde (IOPS) de 10 à 16 disques, le rôle serveur de boîtes aux lettres n’utilisera à lui seul pas plus de la moitié des ressources processeur disponibles. L’ajout du rôle serveur d’accès au client et du rôle serveur de transport Hub à ce serveur permettra d’exploiter plus efficacement sa capacité.
Vous pouvez utiliser les informations de cette rubrique pour savoir quand déployer des configurations de serveurs multirôles et comment planifier correctement des configurations de serveurs multirôles. Un exemple illustre le processus de dimensionnement des serveurs multirôles.
Contenu de cette rubrique
Pourquoi des configurations multirôles sont-elles recommandées ?
Quand des configurations multirôles sont-elles recommandées ?
Quand des configurations multirôles ne sont-elles pas recommandées ?
Configurations matérielles recommandées pour les serveurs multirôles
Déploiement d’un serveur multirôles dans un groupe de disponibilité de base de données
Exemple de dimensionnement pour un scénario multirôles Exchange 2010
Pourquoi des configurations multirôles sont-elles recommandées ?
Tout d’abord, et avant tout, le matériel que vous pouvez vous procurer aujourd’hui est composé de processeurs extrêmement rapides, atteignant 5 000 à 6 000 mégacycles par rapport à notre configuration de processeur de la ligne de base. Cette configuration consiste en 2 processeurs à 4 cœurs Intel Xeon x 5470 3,33 GHz. (Vous trouverez des informations complémentaires sur la configuration de processeur de la ligne de base dans la rubrique « Exemple de planification de capacité pour un serveur de boîtes aux lettre » dans Planification des capacités du processeur du serveur de boîtes aux lettres.) Si remplacez l’architecture de processeur dans un environnement par des processeurs actuellement disponibles sur le marché tout en ne changeant aucun autre facteur environnemental, vous remarquerez une diminution significative de l’utilisation des processeurs.
Pour diminuer de manière effective le coût total de possession des serveurs que vous achetez, vous devez assurer une utilisation efficace du système, ce qui signifie que le système doit atteindre et maintenir une utilisation de 80 % du processeur pendant la charge de pointe en mode de pire défaillance. Voici quatre manières d’utiliser efficacement les processeurs disponibles actuellement :
Augmenter la charge de travail en déployant plus de boîtes aux lettres actives par serveur.
Introduire une couche de virtualisation et déployer le rôle Mailbox en tant qu’ordinateur invité ainsi que des ordinateurs invités supplémentaires.
Déployer des rôles serveur Exchange supplémentaires dans le système.
Utiliser une combinaison des méthodes citées ci-dessus pour trouver la configuration optimale utilisant le matériel de la manière la plus efficace possible.
Déployer Exchange 2010 avec une architecture multirôles présente plusieurs avantages :
L’architecture multirôles devient une architecture basée sur un bloc de construction. Avec l’architecture multirôles, tous les serveurs dans l’environnement Exchange (messagerie unifiée et transport Edge exclus) sont exactement les mêmes : le même matériel, la même configuration ... L’uniformité simplifie la commande du matériel ainsi que la maintenance et la gestion des serveurs.
- En ce qui concerne les coûts, le but global est d’assurer un équilibre de l’architecture du point de vue des processeurs comme du disque. Le déploiement de rôles serveur sur différents ordinateurs peut entraîner à long terme des désavantages en matière de coûts car vous pourriez être amené à acheter plus de processeurs, de disques et de ressources mémoire que vous n’en utilisez réellement. Considérez par exemple un serveur qui héberge uniquement le rôle serveur d’accès au client. Beaucoup de serveurs vous permettent d’ajouter un certain nombre de disques de manière rentable. Le coût est de pratiquement nul lorsque vous déployez ce nombre de disques et les utilisez (ce qui est encore plus important). Mais si vous déployez un rôle serveur qui utilise beaucoup moins de disques que le nombre donné, vous payez pour un contrôleur de disque que vous sous-exploitez ou n’exploitez pas du tout.
Dans beaucoup de cas, l’utilisation d’architectures multirôles vous permet d’avoir moins de serveurs Exchange physiques dans l’environnement. Un nombre réduit de serveurs physiques signifie une réduction des coûts pour diverses raisons :
Les coûts d’exploitation sont presque toujours plus élevés que les dépenses en capital. La gestion d’un serveur tout a long de son cycle de vie coûte plus cher que son achat.
Vous achetez moins de licences de serveur Exchange. Un serveur multirôles requiert une licence pour un serveur Exchange et un système d’exploitation, alors qu’une séparation des rôles requiert plusieurs licences de serveur Exchange, voire même plusieurs licences de système d’exploitation. Pour plus d’informations, voir À propos de la licence : licence pour les environnements virtuels (peut être en anglais).
L’effet du déploiement d’un nombre limité de serveurs se répercute sur le reste de l’infrastructure. Par exemple, le déploiement d’un nombre limité de serveurs peut réduire le nombre de châssis et l’espace requis pour l’infrastructure Exchange, ce qui réduit alors les coûts d’électricité et de refroidissement.
Une architecture multirôles répartit la charge sur un nombre de serveurs plus important que dans une architecture à serveurs à rôle unique car tous les serveurs de boîtes aux lettres deviennent également des serveurs de transport Hub et des serveurs d’accès au client. Cette architecture apporte deux avantages :
Du point de vue de l’évolutivité, vous distribuez la charge sur un nombre plus important d’ordinateurs physiques. Pendant un événement d’échec, la charge accrue sur les serveurs restants augmente uniquement de manière incrémentale, ce qui garantit que les autres fonctions exécutées par le serveur ne sont pas affectées.
Du point de vue de la résilience, la solution peut résister à un nombre plus important d’échecs des rôles (ou services) Hub Transport et Client Access et continuer à assurer des services.
Pour ces raisons, nous recommandons pour la plupart des scénarios une configuration de serveur multirôles comme stratégie de déploiement pour Exchange 2010.
Quand des configurations multirôles sont-elles recommandées ?
Les configurations multirôles sont recommandées pour la plupart des scénarios pour les raisons suivantes :
Modèle de simple unité d’échelle Les organisations anticipant une croissance régulière du nombre de leurs boîtes aux lettres doivent envisager le déploiement de serveurs multirôles. Chaque serveur multirôles représentant un bloc de construction, ce modèle permet d’ajouter facilement des blocs de construction pour répondre aux besoins d’augmentation de capacité.
Déploiements à grande échelle visant à exploiter des processeurs modernes Sur la base de tests d’évolutivité effectués avant la mise à disposition de la version de publication (RTM) d’Exchange 2010, les serveurs multirôles peuvent utiliser efficacement des processeurs hex core (ou plus) au sein d’un seul serveur. Cette capacité permet aux grandes entreprises de réduire le nombre de leurs serveurs en combinant les rôles serveur Boîte aux lettres, Transport Hub et Accès au client au lieu de déployer séparément ces rôles sur des serveurs équipés de moins de cœurs. Cette approche tire parti du modèle de bloc de construction décrit précédemment pour fournir une plate-forme multifonctions adaptée aux déploiements à grande échelle, tout en réduisant le nombre global de serveurs nécessaires. L’évolutivité de la configuration multirôles sur des systèmes à plus grand nombre de cœurs doit être validée par des tests en laboratoire avant un déploiement en production.
Déploiements de serveurs avec stockage interne De nombreux serveurs actuels possèdent deux processeurs multicœur physiques et 10 à 16 disques internes. Plusieurs améliorations apportées à Exchange 2010 réduisent les besoins en E/S et font de ces serveurs une solution rentable En fonction du profil de l’utilisateur et du type de disque, ces serveurs prennent généralement en charge jusqu’à 4 000 boîtes aux lettres. Nous recommandons d’ajouter les rôles serveur d’accès au client et de transport Hub à ces serveurs pour exploiter les ressources processeur supplémentaires et faire de ces serveurs des blocs de construction autonomes.
Scénarios de minimisation des risques lorsque le nombre de boîtes aux lettres hébergées par un serveur de boîtes aux lettres est limité Les serveurs multirôles représentent une solution pour les déploiements dans lesquels les stratégies de gestion des risques limitent le nombre de boîtes aux lettres pouvant être déployées sur un serveur de boîtes aux lettres. Par exemple, une organisation possédant 10 000 boîtes aux lettres dispose d’une stratégie prévenant qu’une défaillance d’un serveur n’affecte plus de 25 % des boîtes aux lettres de l’environnement. Le nombre requis de boîtes aux lettres par serveur de boîtes aux lettres est donc limité à 2 500. La capacité additionnelle de ce serveur pourrait être exploitée en ajoutant des rôles serveur d’accès au client et transport Hub à ce serveur.
Déploiements dans des organisations de petite taille et des filiales À l’exception du cas cité ci-dessous lorsque l’équilibrage de la charge réseau Windows est utilisé, un déploiement multirôles est la solution recommandée pour les déploiements dont les buts principaux sont de minimiser le nombre de serveurs physiques, d’instances de systèmes d’exploitation et de serveurs Exchange à gérer. L’exécution des rôles serveurs d’accès au client, de transport Hub et de boîtes aux lettres sur le même serveur physique fournit la redondance de rôles nécessaire avec une configuration minimale de deux ou trois serveurs physiques.
Pourquoi des configurations multirôles sont-elles recommandées ?
Quand des configurations multirôles ne sont-elles pas recommandées ?
Les configurations multirôles ne sont pas recommandées pour les scénarios suivants :
Déploiements dans des organisations de petite taille et des filiales souhaitant utiliser l’Équilibrage de la charge réseau (NLB) Windows Il se peut que des serveurs multirôles ne fonctionnent pas correctement dans les déploiements de petite taille où deux ou trois serveurs multirôles sont déployés comme membres d’un groupe de disponibilité de base de données (DAG). Pour plus d’informations sur les groupes de disponibilité de base de données, consultez la rubrique Gestion de groupes de disponibilité de base de données. Le composant de clustering ajouté aux serveurs de boîtes aux lettres appartenant à un groupe de disponibilité de base de données prévient l’installation du Gestionnaire d’équilibrage de la charge réseau Microsoft Windows sur le serveur. Pour plus d’informations sur les recommandations concernant l’équilibrage de charge, consultez la rubrique Présentation de l’équilibrage de la charge dans Exchange 2010. Toutefois, il reste nécessaire d’équilibrer la charge du trafic entrant pour les serveurs d’accès au client. Dans ce cas, il existe deux options principales :
Acheter un système matériel d’équilibrage de charge. Bien qu’il existe des systèmes d’équilibrage de charge réseau en entrée de gamme, cette option peut s’avérer onéreuse, notamment dans des environnements de petites dimensions.
Virtualiser les rôles serveur d’Exchange. Dans certains environnements, un nombre limité de serveurs oblige à déployer des contrôleurs de domaine, des serveurs de fichiers et d’impression ainsi que d’autres applications sur le même matériel physique que les serveurs Exchange 2010. Nous vous recommandons d’implémenter les serveurs physiques comme des serveurs hôtes et d’isoler les applications dans un environnement virtuel. Cette isolation vous permet d’exécuter le gestionnaire d’équilibrage de charge réseau pour les serveurs d’accès au client fonctionnant sur des machines virtuelles.
Virtualisation Le nombre maximum de boîtes aux lettres actives pouvant être hébergées par une machine virtuelle peut être réduit selon la combinaison du profil de message et des boîtes aux lettres exécutées dans une configuration multirôles. Si vos utilisateurs n’envoient pas un grand nombre de messages, il peut être utile de rassembler les rôles serveur au sein d’un ordinateur virtuel. Cependant, si vos utilisateurs envoient beaucoup de messages, il se peut que les ressources d’une machine virtuelle ne soient pas suffisantes, et que vous deviez réduire le nombre de boîtes aux lettres par ordinateurs virtuels de serveur de boîte aux lettres ou répartir les rôles sur plusieurs ordinateurs virtuels. Dans ces cas, il plus efficace de déployer un seul rôle serveur Exchange sur chaque ordinateur virtuel ou de déployer une machine virtuelle combinant les rôles serveur d’accès au client et transport Hub pour chaque ordinateur virtuel de serveur de boîte aux lettres.
.gif "Remarque")
Remarque :Vous ne pouvez pas installer un rôle serveur Exchange sur le serveur hôte hyperviseur. Seuls les logiciels de gestion (par exemple, logiciel antivirus, logiciel de sauvegarde, logiciel de gestion des ordinateurs virtuels) peuvent être déployés sur les serveurs hôtes. Aucune autre application serveur (par exemple, Exchange, Microsoft SQL Server, ou Active Directory) ne doit être installée sur le serveur hôte. Les serveurs hôtes doivent être dédiés à l’exécution des ordinateurs virtuels invités.
Pour plus d’informations, voir Présentation des configurations des rôles combinés d'accès au client et de transport Hub dans la planification de capacité.
Pourquoi des configurations multirôles sont-elles recommandées ?
Configurations matérielles recommandées pour les serveurs multirôles
De manière générale, un serveur multirôles doit être dimensionné de manière à utiliser la moitié des cœurs de processeur disponibles pour le rôle serveur de boîtes aux lettres et utiliser l’autre moitié pour les rôles serveur d’accès au client et de transport Hub. Microsoft ne spécifie pas de nombre maximum de cœurs de processeur recommandé pour les serveurs multirôles. Au lieu de cela, un nombre maximal de sockets de processeur utilisés est fourni. Ceci dépend du nombre de sockets de processeur sur la carte mère à laquelle des processeurs multicœur sont connectés. Pour plus d’informations, voir Présentation des configurations de processeur et des performances d’Exchange.
En plus du dimensionnement de l’architecture de processeur, la mémoire doit également être dimensionnée correctement pour le déploiement d’une configuration multirôles. Pour plus d’informations, voir Présentation des configurations mémoire et des performances Exchange.
Déploiement d’un serveur multirôles dans un groupe de disponibilité de base de données
Lorsque vous déployez des serveurs de boîtes aux lettres à rôle unique dans un groupe de disponibilité de base de données, considérez la planification de capacité en cas de défaillance d’un ou de plusieurs serveurs par rapport à la charge du serveur de boîtes aux lettres. Si vous avez quatre serveurs de boîtes aux lettres dans un groupe de disponibilité de base de données, dimensionnez ces serveurs à 50 % de capacité pour qu’ils puissent accepter le double du nombre d’utilisateurs actifs dans le cas d’une défaillance simultanée de deux serveurs de boîtes aux lettres. Puisque les serveurs de transport Hub et d’accès au client sont sur des serveurs physiques différents, la charge supportée par ces serveurs n’est guère modifiée par la perte d’un ou deux serveurs de boîtes aux lettres.
Lorsque vous déployez des serveurs multirôles dans un groupe de disponibilité de base de données, réfléchissez à la planification de capacité pour la charge des serveurs d’accès au client, de transport Hub et de boîtes aux lettres. Si vous avez des serveurs multirôles dans un groupe de disponibilité de base de données, assurez-vous que la capacité est suffisante pour prendre en charge un doublement potentiel de la charge des serveurs de transport Hub et d’accès au client. Puisque la configuration multirôles s’aligne sur les ratios recommandés pour les cœurs de processeur, un dimensionnement correct du nombre maximal de bases de données actives pour les rôles serveur de boîtes aux lettres, transport Hub et accès au client doit répondre aux objectifs de performances pour ce scénario.
Pourquoi des configurations multirôles sont-elles recommandées ?
Exemple de dimensionnement pour un scénario multirôles Exchange 2010
L’exemple suivant illustre le processus de dimensionnement des serveurs multirôles. L’exemple comprend les hypothèses de conception suivantes :
Nombre total de boîtes aux lettres 24 000
Profil de boîte aux lettres 100 messages par jour (par exemple, 20 envoyés et 80 reçus)
Cache de la base de données par boîte aux lettres 6 Mo (sur la base d’un profil de 100 messages par jour)
Exigences de disponibilité Résilience de boîte aux lettres au sein d’un seul site ; protection contre la défaillance simultanée de trois copies de base de données et de deux serveurs
Besoins en base de données 120 bases de données dans le groupe de disponibilité de bases de données, 200 boîtes aux lettres par base de données
Plate-forme du serveur Serveur composé de 2 processeurs à six cœurs (X5650), 2,26 gigahertz (GHz) (12 cœurs)
La procédure suivante s’applique :
Calcul du nombre de serveurs Un groupe de disponibilité de base de données à quatre nœuds doit protéger contre la défaillance simultanée de deux serveurs. Cependant, le client a décidé de déployer six serveurs pour contrôler le plus grand nombre possible de boîtes aux lettres actives en cas de défaillance de deux serveurs. La conception commence alors avec six serveurs de boîtes aux lettres au sein du groupe de disponibilité de base de données.
Calcul du nombre maximum de boîtes aux lettres actives par serveur selon le modèle d’activation Si les bases de données actives sont réparties de manière égale sur tous les nœuds, chaque serveur héberge idéalement 4 000 boîtes aux lettres actives (24 000 ÷ 6). Pour calculer le nombre de boîtes aux lettre après une double défaillance de nœuds (sur la base de cet exemple), le nombre de boîtes aux lettres est divisé par les quatre nœuds restants, ce qui équivaut à 6 000 boîtes aux lettres actives par nœud (24 000 ÷ 4).
Dans cet exemple, le paramètre MaximumActiveDatabases de la cmdlet Set-MailboxServer est configuré sur 30 pour garantir que moins de 40 % des bases de données ne deviennent actives sur un seul serveur.
Calculer les besoins en processeur des boîtes aux lettres actives Multipliez le nombre de boîtes aux lettres actives sur un serveur par le nombre de mégacycles par boîte aux lettres active (6 000 × 2 mégacycles = 12 000 mégacycles), en se basant sur le tableau ESPS estimées par boîte aux lettres en fonction de l’activité de messagerie et du cache de base de données de boîte aux lettres dans la rubrique Présentation du cache de la base de données de boîtes aux lettres. Multipliez cette valeur de 10 pour cent pour chaque copie de base de données supplémentaire.
Dans cet exemple, chaque base de données comporte une copie active et trois copies passives. Par conséquent les 12 000 mégacycles sont incrémentés de 30 % (12 000 × 1,3 = 15 600 mégacycles). Pour plus d’informations, voir la section « Mesures de cache de base de données » dans la rubrique Présentation du cache de la base de données de boîtes aux lettres.
Calculer les besoins en processeur des boîtes aux lettres passives Multipliez le nombre de boîtes aux lettres passives (lorsqu’un serveur héberge le nombre maximal de boîtes aux lettres actives) par le nombre de mégacycles par boîte aux lettres passive (10 000 × 0,3 mégacycles = 3 000 mégacycles), en se basant sur le tableau ESPS estimées par boîte aux lettres en fonction de l’activité de messagerie et du cache de base de données de boîte aux lettres dans la rubrique Présentation du cache de la base de données de boîtes aux lettres. Pour plus d’informations, voir la section « Mesures de cache de base de données » dans la rubrique Présentation du cache de la base de données de boîtes aux lettres.
**Additionner les besoins en processeur des boîtes actives et passives pour obtenir le chiffre total des besoins en processeur **Dans cet exemple, 15 600 mégacycles de boîtes aux lettres actives + 3 000 mégacycles de boîtes aux lettres passives = 18 600 mégacycles au total.
Appliquer les besoins en processeur des boîtes aux lettres à la plate-forme matérielle Cet exemple utilise un serveur composé de 2 processeurs à six cœurs (x5650) de 2,26 GHz. Selon les recommandations figurant dans Planification des capacités du processeur du serveur de boîtes aux lettres, cela équivaut à 60 083 mégacycles. Divisez le nombre de mégacycles requis par le nombre de mégacycles disponibles en fonction de la plate-forme du serveur pour estimer le taux d’utilisation du processeur pendant une période de pointe après une double défaillance de nœuds (18 600 ÷ 60 083 = 31 % d’utilisation du processeur prévus).
Il est recommandé que la partie rôle serveur de boîte aux lettres dans une configuration multirôles soit conçue pour ne pas dépasser 40 % d’utilisation aux périodes de pointe (par exemple, en cas de défaillance simultanée de deux nœuds). Cette conception laisse un espace suffisant pour permettre l’utilisation du processeur par les rôles serveurs d’accès au client et de transport Hub tout en maintenant un taux total d’utilisation du processeur inférieur à 80 % pendant les périodes de pointe (par exemple, en cas de défaillance simultanée de deux nœuds).
Calculer les besoins en mémoire des boîtes aux lettres actives Multipliez le nombre de boîtes aux lettres actives par le cache de base de données requis par boîte aux lettres. Dans cet exemple avec une défaillance simultanée de deux serveurs, les serveurs restants hébergeront 6 000 boîtes aux lettres actives (6 000 × 6 Mo) ÷ 1,024 = 35.1 Go. Les besoins en cache de base de données sont fonction du profil de boîte aux lettres. Pour plus d’informations, voir la section « Mesures de cache de base de données » dans la rubrique Présentation du cache de la base de données de boîtes aux lettres.
Appliquer la configuration mémoire totale requise à la plate-forme matérielle La capacité mémoire totale requise varie en fonction des spécifications du cache de la base de données et de la conception du serveur (dédié ou multirôles). Pour plus d’informations, reportez-vous au tableau Tailles de cache de base de données de boîte aux lettres par défaut dans la rubrique Présentation du cache de la base de données de boîtes aux lettres. La capacité mémoire totale requise pour le serveur multirôles dans cet exemple est de 52,2 Go ((4 Go + 35,1 Go) ÷ 0,75). Comme 52,2 Go n’est pas une configuration mémoire standard, arrondissez la configuration de votre mémoire à 64 Go ou à la capacité la plus proche prise en charge par votre serveur.
Pourquoi des configurations multirôles sont-elles recommandées ?
© 2010 Microsoft Corporation. Tous droits réservés.