Virtualisation d'Exchange 2007 SP1

Dernière rubrique modifiée : 2009-03-02

Grâce à la version de Windows Server 2008 incluant la technologie Hyper-V et à Microsoft Hyper-V Server 2008, les serveurs Microsoft Exchange Server 2007 Service Pack 1 (SP1) virtualisés ne sont plus limités à l'univers du laboratoire. Désormais, ils peuvent être déployés dans un environnement de production et recevoir une prise en charge complète de Microsoft. En août 2008, Microsoft a publié des stratégies de prise en charge et des recommandations pour la virtualisation d'Exchange. Cet article répond à une question plus pratique : la virtualisation est-elle adaptée à Exchange ?

En raison des impératifs d'Exchange Server liés aux performances et à l'entreprise, la plupart des installations tirent parti du déploiement des rôles serveur Exchange sur les serveurs physiques. Il existe toutefois certains scénarios pour lesquels l'exécution d'Exchange dans un environnement de virtualisation de matériel offre de réels avantages en termes d'espace, de puissance et de flexibilité de déploiement. Cet article aborde les aspects suivants :

• Scénarios   Cette section décrit quatre scénarios pour lesquels il peut être opportun de procéder à la virtualisation d'Exchange 2007 SP1.

• Listes de contrôle techniques   Cette section inclut des listes de contrôle qui permettent de déterminer si la charge actuelle de votre infrastructure justifie une virtualisation.

Scénarios

Cette section décrit les quatre scénarios suivants 

• Petite entreprise à haute disponibilité

• Bureau distant ou filiale à haute disponibilité

• Récupération d'urgence

• Réseau local mobile

Petite entreprise à haute disponibilité

Malgré leur petite taille, certaines organisations nécessitent une disponibilité de classe entreprise. Prenons l'exemple de Contoso Ltd., une entreprise fictive qui considère la messagerie comme un service critique. Contoso compte plusieurs petites filiales regroupant 250 utilisateurs. L'entreprise souhaite conserver son environnement de messagerie sur site pour des raisons légales et disposer d'un système de messagerie entièrement redondant. Les utilisateurs de Contoso ont des profils de messagerie d'utilisateur moyen avec des boîtes aux lettres de 2 Go.

Pour obtenir une redondance totale des rôles serveur Exchange à l'aide de matériel physique, Contoso doit déployer sept serveurs : deux serveurs pour Active Directory et DNS, un serveur pour les services de fichiers et d'impression, deux serveurs exécutant chacun les rôles serveur d'accès au client et de transport Hub, et deux serveurs exécutant le rôle serveur de boîtes aux lettre dans un environnement de réplication continue en cluster (CCR). Ces serveurs sont équipés de deux processeurs quadri-cœur. La quantité de RAM est définie conformément aux recommandations de Microsoft pour chaque rôle installé. Chaque nœud CCR a 4 Go de RAM. Chacun des autres serveurs a au minimum 2 Go de RAM pour prendre en charge les utilisateurs et les modèles de trafic. En présence de profils de messagerie d'utilisateur moyen, la charge normale doit utiliser 35 à 45 % du processeur sur un serveur à huit cœurs.

La virtualisation permet à Contoso d'obtenir le même niveau de redondance et de disponibilité avec seulement trois serveurs. Chaque serveur physique exécute plusieurs serveurs virtualisés comme ordinateurs invités. Dans ce scénario, trois serveurs physiques dotés de deux processeurs quadri-cœur et de 16 Go de RAM présentent une capacité suffisante pour servir les utilisateurs de Contoso. Chacun des serveurs virtuels est configuré avec deux processeurs virtuels. Outre la RAM et les processeurs, les serveurs doivent avoir plusieurs cartes réseau et des chemins redondants pour le stockage. Contoso doit toujours gérer le même nombre de serveurs Exchange et ne tire donc aucun bénéfice de la virtualisation du point de vue des opérations et de la maintenance. En revanche, l'entreprise gagne en espace, en puissance et en refroidissement.

Le diagramme suivant illustre le scénario.

Dans ce scénario, le passage de sept serveurs physiques à trois serveurs physiques et sept serveurs virtuels doit permettre de réduire la consommation énergétique de 25 754 kWh et d'économiser 22 516 dollars par an. L'outil de virtualisation de Microsoft a permis de rassembler ces données.

Le dimensionnement d'Exchange pour un environnement de virtualisation de matériel est semblable au dimensionnement d'Exchange pour des serveurs physiques. Que vous utilisiez des serveurs physiques ou virtualisés, chaque nœud CCR requiert 4 Go de RAM et un stockage capable de prendre en charge 48 E/S par seconde pour les bases de données et 19 E/S par seconde pour les journaux des transactions. Dans ce scénario, les exigences relatives aux E/S par seconde sont très faibles et doivent pouvoir être maintenues dans un environnement virtualisé. L'utilisation de disques durs virtuels fixes doit suffire pour cette solution étant donné le petit nombre d'utilisateurs hébergés sur les serveurs Exchange virtualisés. Pour les populations d'utilisateurs plus élevées, il est recommandé d'utiliser un stockage externe.

Retour au début

Bureau distant ou filiale à haute disponibilité

Auparavant, certaines organisations installaient des serveurs Exchange locaux dans les bureaux distants ou les filiales pour offrir des performances suffisantes aux utilisateurs dans ces sites. Avec des améliorations telles que le mode Exchange mis en cache et Outlook Anywhere, la consolidation de ces serveurs au sein d'un centre de données est devenue l'approche recommandée.

Dans certaines situations, une connectivité réseau médiocre vers les bureaux distants oblige encore certaines organisations à doter les sites affectés d'un serveur Exchange local. Le plus souvent, la taille extrêmement réduite des populations d'utilisateurs au sein de ces sites ne justifie pas de dédier un serveur physique à l'environnement Exchange. Les considérations techniques dans ce scénario sont les mêmes que celles décrites dans le scénario « Petite entreprise à haute disponibilité » ci-avant. Pour consulter un exemple de ce scénario dans lequel une entreprise a utilisé Exchange 2007 SP1 dans un environnement Hyper-V, téléchargez cette étude de cas sur les solutions client Windows Server 2008 relative au Caspian Pipeline Consortium (en anglais).

Récupération d'urgence

Pour assurer la résilience et la redondance d'un site de production, certaines organisations peuvent nécessiter un site quasi-opérationnel qui reproduit l'infrastructure Exchange 2007 de production principale. En cas de perte du site principal, ce type de site est destiné à fournir un niveau de fonctionnalité aussi proche que possible de celui du site principal. S'il s'agit d'une démarche utile en relation avec les exigences de contrat de niveau de service (SLA), conserver une infrastructure dupliquée de secours peut être financièrement inabordable pour certaines organisations.

Pour réduire ces coûts, il est possible de créer une copie de l'ensemble du site principal à l'aide d'ordinateurs invités dans un environnement Hyper-V. Une configuration de site quasi-opérationnel classique basée sur des serveurs Exchange 2007 physiques inclut un ou plusieurs serveurs configurés ensemble comme cluster de secours, et un ou plusieurs autres serveurs configurés comme rôles serveur d'accès au client et de transport Hub. Quatre serveurs physiques sont nécessaires pour assurer la redondance des seuls services de messagerie au sein du site quasi-opérationnel. En comparaison, une solution virtualisée avec trois serveurs physiques peut offrir un site quasi-opérationnel incluant deux serveurs de boîtes aux lettres dans un environnement CCR, ainsi que des serveurs d'accès au client et de transport Hub redondants. Dans ce scénario, la virtualisation d'Exchange offre un niveau de services plus élevé aux utilisateurs et réduit l'espace requis et les coûts matériels, énergétiques et de refroidissement par rapport à une solution configurée à l'identique, mais déployée sur des serveurs physiques.

Le diagramme suivant illustre cette configuration.

Le site principal utilise du matériel physique en raison de la taille et du profil de messagerie exigeants de la population d'utilisateurs. Dans ce scénario, le site quasi-opérationnel est conçu pour prendre en charge l'ensemble de la population d'utilisateurs du site principal. Même si l'utilisation du site quasi-opérationnel est temporaire et implique des performances réduites, la configuration de l'environnement qui prendra en charge la population d'utilisateurs doit être considérée avec soin.

Sur le diagramme, le site quasi-opérationnel contient un cluster de secours dont l'un des nœuds est configuré comme cible de réplication continue en attente (SCR) pour l'environnement CCR de production. Une paire de contrôleurs de domaine est également déployée. La cible SCR est un cluster de secours à deux nœuds. En cas de défaillance du site, le cluster de secours est activé à l'aide de la cmdlet Restore-StorageGroupCopy, puis le serveur de boîtes aux lettres en cluster est récupéré à l'aide du commutateur Setup /recoverCMS. Les mêmes procédures de récupération d'urgence via un cluster de secours s'appliquent, même si le cluster de secours est un ordinateur invité dans un environnement de virtualisation de matériel. Une fois que le cluster de secours est en ligne et héberge le serveur de boîtes aux lettres en cluster du site défaillant, l'accès client aux services et données de messagerie est restauré après la réplication de DNS et d'Active Directory.

En cas de perte du site principal, le site quasi-opérationnel virtuel doit pouvoir fournir aux utilisateurs un niveau de service adéquat (probablement réduit en raison des liens WAN/Internet vers le site quasi-opérationnel). Le site étant conçu pour fournir des fonctionnalités d'urgence au cours d'une période brève, ce niveau de service réduit doit être acceptable. En revanche, la résilience du site quasi-opérationnel est inexistante pendant la panne du site principal.

Dans ce scénario, le passage de huit serveurs physiques à trois serveurs physiques et huit serveurs virtuels doit permettre de réduire la consommation énergétique de 33 005 kWh et d'économiser 28 225 dollars par an. L'outil de virtualisation de Microsoft a permis de rassembler ces données.

Retour au début

Réseau local mobile

Il arrive parfois qu'un service d'une entreprise, d'une agence ou d'une administration ait besoin d'une infrastructure réseau complète rapidement déployable à des emplacements spécifiques. Cette infrastructure est ensuite connectée au réseau de l'organisation par satellite ou via une autre technologie WAN distante. Prenons l'exemple d'une organisation non gouvernementale (ONG) qui doit intervenir suite à une catastrophe et configurer des serveurs locaux pour servir la communauté sinistrée. Ce sous-ensemble de serveurs doit être complètement autonome et capable de fournir tous les services utiles au personnel à l'emplacement cible.

En pareil cas, le réseau local mobile doit être facile à transporter. Il doit avoir un format réduit et hautement efficace, fournir tous les services nécessaires aux utilisateurs locaux et utiliser le moins d'espace possible. En raison de l'éloignement probable des emplacements de déploiement du réseau local mobile, il doit également présenter des capacités de tolérance de panne pour garantir l'absence de points de défaillance uniques dans une région où il peut être difficile de trouver des pièces de rechange.

Dans ce scénario, un serveur Hyper-V peut être utilisé pour héberger les services Exchange, les services de serveur de fichiers et les services d'infrastructure du domaine dans un format compact.

Le diagramme suivant illustre la configuration possible d'un serveur Hyper-V hébergeant les systèmes Exchange 2007 et d'infrastructure du domaine. En raison de la nature du scénario, aucun des rôles serveur Exchange n'a été combiné sur le même ordinateur invité.

Le diagramme montre une solution réseau complète pour une organisation qui nécessite que tous les services de serveur nécessaires soient fournis localement, indépendamment de l'emplacement. La solution est aussi réduite que possible et offre un degré élevé de tolérance de panne et de disponibilité du système.

Dans le rack, vous aurez également besoin d'équipements d'infrastructure réseau en quantité suffisante pour prendre en charge les serveurs racines hyperviseurs et les stations de travail. Les systèmes racines hyperviseurs utilisent un réseau SAN de type iSCSI ou Fiber Channel. Le réseau SAN doit comporter suffisamment de piles pour offrir les performances nécessaires aux systèmes invités. Dans ce scénario, tous les éléments requis tiennent dans un rack de 42U.

Dans ce scénario, le passage de 14 serveurs physiques à trois serveurs physiques et 14 serveurs virtuels doit permettre de réduire la consommation énergétique de 91 012 kWh et d'économiser 73 891 dollars par an. L'outil de virtualisation de Microsoft a permis de rassembler ces données.

Retour au début

Listes de contrôle techniques

Dans chacun des scénarios décrits ci-avant, le déploiement d'Exchange sur du matériel physique aurait entraîné une sous-utilisation des ressources. Vous pouvez utiliser les listes de contrôle suivantes pour déterminer si la consolidation de votre environnement Exchange pourrait s'avérer avantageuse. Si ces listes de contrôle révèlent que votre matériel est sous-utilisé, vous devez envisager les actions possibles suivantes :

• Si vous êtes une petite organisation, vous pouvez peut-être réduire l'empreinte de vos serveurs physiques à trois serveurs physiques avec une redondance totale des rôles Exchange grâce à la virtualisation.

• Si le matériel sous-utilisé se trouve dans une filiale ou un bureau distant qui ne peut pas être consolidé au sein d'un centre de données, vous pouvez peut-être réduire l'empreinte de vos serveurs physiques à cet emplacement grâce à la virtualisation.

• Dans d'autres scénarios, vous pouvez alléger votre environnement Exchange en réévaluant l'adéquation de la capacité des serveurs à la charge utilisateur. Vous pouvez réduire le nombre de serveurs physiques pour optimiser l'utilisation aux niveaux souhaités. Dans ce scénario, il n'est pas nécessaire d'utiliser la virtualisation.

Gardez à l'esprit qu'un matériel sous-utilisé signifie simplement que votre environnement Exchange présente un excédent de capacité. Cette situation peut découler de la conception (prise en charge des pics d'utilisation ou d'une croissance imprévue) ou non. Un excès de capacité est souhaitable. Ce facteur est d'ailleurs pris en compte dans les listes de contrôle suivantes.

Liste de contrôle 1 – Compteurs de performance

La liste de contrôle suivante répertorie les compteurs de performance à surveiller pour déterminer si votre environnement Exchange est sous-utilisé. Ces compteurs doivent être collectés à partir des serveurs Exchange physiques et non des serveurs Exchange virtualisés. Comme la planification de l'infrastructure Exchange est basée sur le rôle serveur de boîtes aux lettres, les listes de contrôle ci-après utilisent principalement les métriques du serveur de boîtes aux lettres.

Il est recommandé de relever chacun de ces compteurs à des intervalles réguliers pendant une semaine au minimum. Une fois les données collectées, vous pouvez comparer les résultats aux valeurs attendues. Si les valeurs observées sont inférieures aux valeurs attendues ci-après, votre matériel de serveur est sous-utilisé.

Les compteurs de la liste de contrôle proviennent de la page Surveillance sans System Center Operations Manager. Vous devez vous assurer que vous surveillez vos serveurs une fois qu'ils sont mis en production.

Liste de contrôle des compteurs de performance

Retour au début

Liste de contrôle 2 – Facteurs de profil utilisateur

Pour déterminer plus rapidement (mais avec moins de précision) si vos serveurs sont sous-utilisés, vous pouvez comparer les cœurs de processeur aux profils utilisateur en suivant les instructions générales de dimensionnement de l'article Planification des configurations de processeur et de mémoire. Pour identifier le profil utilisateur de votre organisation, reportez-vous au tableau des profils utilisateur de l'article (reproduit ci-après).

En règle générale, 1 000 boîtes aux lettes de profil moyen actives nécessitent un cœur de processeur (voir l'article Planification des configurations de processeur et de mémoire). Par exemple, un serveur de 4 000 boîtes aux lettres avec un profil d'utilisation moyen nécessite quatre cœurs de processeur. Un profil d'utilisation très actif nécessitant davantage de cycles de processeurs qu'un profil moyen, utilisez 750 boîtes aux lettres au profil très actif par cœur de processeur à des fins de planification. La liste de contrôle suivante s'appuie sur cette logique pour estimer le nombre d'utilisateurs nécessaires pour utiliser entièrement un cœur de processeur :

Liste de contrôle des facteurs de profil utilisateur

Le nombre recommandé d'utilisateurs moyens étant de 1 000 par cœur de processeur, une population d'utilisateurs actifs de 500 boîtes aux lettres de profil moyen ou inférieur indique qu'il n'y a pas assez d'utilisateurs pour utiliser entièrement un cœur de processeur de serveur de boîtes aux lettres. Gardez à l'esprit que, pour les serveurs Exchange physiques, huit est le nombre maximal de cœurs de processeur utilisés efficacement par le rôle serveur de boîtes aux lettres (voir l'article Planification des configurations de processeur et de mémoire). Le déploiement des boîtes aux lettres sur les serveurs ayant plus de huit cœurs ne fournira pas des améliorations d'évolutivité importantes.

L'utilisation de cette liste de contrôle pour évaluer le nombre de cœurs de processeur d'un serveur de boîtes aux lettres est un point de départ idéal pour réexaminer les autres rôles serveur Exchange. En effet, la méthodologie de planification de l'infrastructure Exchange pour les serveurs de transport Hub et d'accès au client est en partie basée sur le ratio de cœur de processeur par rapport au serveur de boîtes aux lettres (Boîtes aux lettres/Hub et Boîtes aux lettres/CAS). Par exemple, le ratio Boîtes aux lettres/Hub est de 5/1 si les serveurs de transport Hub exécutent des antivirus de transport, et de 7/1 dans le cas contraire. Par conséquent, si une population d'utilisateurs n'est pas susceptible d'utiliser entièrement un cœur de processeur de serveur de boîtes aux lettres, il en sera probablement de même pour un cœur de processeur de transport Hub. Ce constat peut justifier l'utilisation de la virtualisation pour les serveurs de transport Hub et/ou d'accès au client.

Conclusion

La version de Windows Server 2008 avec Hyper-V et, plus récemment, Microsoft Hyper-V Server 2008, permettent de disposer de nouvelles options de déploiement d'Exchange Server 2007 SP1. Très souvent, conserver Exchange sur un matériel physique facilite la gestion et implique un coût total de possession inférieur par rapport à la virtualisation. Il existe toutefois certains scénarios pour lesquels une infrastructure Exchange virtualisée peut offrir de réels avantages en termes d'espace, de puissance et de flexibilité de déploiement.

Le degré de sous-utilisation du matériel actuel est un facteur clé pour déterminer si les avantages de la virtualisation l'emportent sur les complexités liées à l'ajout d'une couche virtuelle sous Exchange. Les avantages de la virtualisation sont généralement réservés aux environnements dans lesquels le déploiement Exchange est trop petit pour mobiliser entièrement les serveurs sous-jacents. Les déploiements Exchange réduits, les sites distants à faible connectivité, certains scénarios de récupération d'urgence et les déploiements de réseau local mobile sont des exemples de situations pour lesquelles la virtualisation peut convenir.

Dans la plupart des organisations, Exchange est une application essentielle. Vous souvenir de ceci pendant la conception de votre environnement virtualisé et suivre les stratégies de prise en charge et recommandations de Microsoft pour les serveurs Exchange virtualisés vous aideront à mettre en place une infrastructure optimisée.

Pour plus d'informations

• Stratégies de prise en charge et recommandations de Microsoft pour les serveurs Exchange dans les environnements de virtualisation de matériel

• Windows Server Virtualization Validation Program(en anglais)

• Configuration requise pour Exchange 2007

• Exchange 2007 Mailbox Server Role Storage Requirements Calculator (en anglais)

• Surveillance sans System Center Operations Manager

• Server Virtualization with Advanced Management Datasheet (en anglais) (téléchargement PDF)