NetApp Tech OnTap
     

Exchange 2010 sur VMware

Si vous songez à exécuter Microsoft® Exchange 2010 sur VMware®, vous trouverez facilement de nombreuses et bonnes raisons de le faire :

  • Utiliser au mieux les cœurs de vos processeurs. Les serveurs volumineux et multicœurs constituent de plus en plus la norme, mais la plupart des applications ne peuvent pas tirer profit de tous les cœurs d'un serveur physique.
  • Isoler les rôles sans augmenter les dépenses matérielles. Exchange 2010 a évolué en une architecture modulaire composée de rôles de serveurs distincts incluant une boîte aux lettres, le transport Edge, le transport de concentrateur et l'accès client. L'isolation de ces rôles peut simplifier le dépannage des problèmes Exchange, mais cela exigerait un grand nombre de serveurs physiques, notamment dans les environnements de petite taille.
  • Éviter le surprovisionnement. Il est toujours compliqué de savoir de quoi demain sera fait en ce qui concerne vos exigences Exchange. L'exécution d'Exchange sur VMware permet de fournir les ressources adéquates aujourd'hui et d'en ajouter de manière incrémentielle au fur et à mesure des besoins, ce qui évite tout surprovisionnement coûteux d'emblée.
  • Respecter plus facilement vos exigences métier. La façon dont vous concevez votre déploiement Exchange peut dépendre de vos exigences spécifiques. Vous avez besoin d'un serveur de boîtes aux lettres séparé pour chaque service ou unité organisationnelle ? Avec la virtualisation, c'est possible : en toute simplicité et sans augmenter les dépenses matérielles ou le nombre de serveurs physiques.
  • Provisionner rapidement un nouveau serveur Exchange. Le provisionnement d'un serveur physique prend du temps, même si vous disposez déjà du matériel nécessaire. Avec VMware, vous pouvez créer facilement un modèle pour chaque type de serveur Exchange et enregistrer vos différents modèles pour accélérer le déploiement à venir des serveurs de même type.
  • Assurer la maintenance d'un laboratoire Exchange. Vous devez assurer la maintenance d'un laboratoire pour tester et dépanner Exchange ? La virtualisation VMware est un point de base exceptionnel pour vos processus d'évaluation et de test pour Exchange 2010.
  • Cloner pour tester et dépanner. Les clones et les copies Snapshot™ vous offrent la possibilité de cloner rapidement un ordinateur virtuel Exchange particulier dans le but de le dépanner.

Malgré ces avantages, et tous les autres, quelques questions restent posées à chaque fois que je discute avec différents utilisateurs de l'exécution d'Exchange sur VMware. Dans cet article, je vais tenter de répondre aux inquiétudes les plus courantes et vous exposer quelques-unes des meilleures pratiques relatives à l'exécution d'Exchange dans les environnements conjoints VMware et NetApp®.

Puis-je obtenir une assistance ?


La question de l'assistance revient très souvent car Microsoft propose des produits de virtualisation compétitifs. Microsoft a récemment apporté deux changements à ses stratégies de licence et d'assistance concernant un grand nombre des problèmes persistants :

  • Assistance pour Exchange 2010 exécuté sur une infrastructure VMware/vSphere™ : VMware ESX™ 3.5 Update 2 a été le premier hyperviseur répertorié dans le cadre du programme Microsoft Server Virtualization Validation Program (SVVP). Cette certification accorde, pour les clients exécutant ESX 3.5 Update 2 ou une version ultérieure (notamment vSphere), Windows® Server 2008 et Exchange Server 2007 SP1 ou Exchange 2010, un accès à une assistance technique coopérative de la part de Microsoft et VMware.
  • Stratégies assouplies pour la mobilité des licences d'applications : Microsoft a mis à jour sa stratégie de licences pour Exchange afin de mieux répondre à l'utilisation dans le cadre d'un environnement virtuel. Les licences d'applications sont toujours liées à un serveur physique, mais Microsoft a supprimé la clause restreignant la réattribution d'une licence d'application à une occurrence tous les 90 jours. Ainsi, vous respectez les dispositions tout en effectuant la migration des ordinateurs virtuels et la haute disponibilité dans un environnement virtuel.

Outre le programme SVVP, vous pouvez également bénéficier d'une assistance directe pour vos applications Microsoft virtualisées en vous inscrivant au programme Microsoft Services Premier Support. Enfin, vous pouvez vous adresser à votre fournisseur de serveurs OEM, au support mondial Global Support Services (GSS) de VMware ou encore au réseau TSANet (Technical Support Alliance Network).

Pour plus d'informations sur l'obtention de l'assistance, consultez le guide de licences et d'assistance pour Microsoft Exchange 2010 sur VMware.

Fonctionnement d'Exchange sur VMware


Mesure des performances

Pour les applications stratégiques telles qu'Exchange, chacun sait à quelles performances s'attendre d'un serveur physique, mais des doutes persistent quant aux performances des serveurs virtualisés. Le meilleur moyen de vous assurer que vous ne rencontrerez aucun problème de performances lors de la virtualisation d'Exchange est de consulter les nombreux tests de performances effectués par VMware et NetApp. La majeure partie du travail a été menée avec Exchange 2007, mais je pense que, notamment du fait de la réduction considérable des E/S entre Exchange 2007 et Exchange 2010, vous pouvez être certain que si les performances étaient bonnes avec Exchange 2007, elles le seront également avec Exchange 2010.

La Figure 1 constitue un résumé des performances d'Exchange sur VMware. Comme vous pouvez le voir, les performances virtuelles se trouvent toujours dans une marge de 5 % par rapport aux performances physiques. Et même avec 4 000 utilisateurs, la charge de CPU n'atteint que 25 %. Le nombre d'utilisateurs lourds évolue de manière linéaire avec l'ajout de CPU dans les cas physiques et virtuels.

Résumé des performances d'Exchange 2007 sur des environnements virtuels en comparaison avec des environnements physiques.

Figure 1) Résumé des performances d'Exchange 2007 sur des environnements virtuels en comparaison avec des environnements physiques.

Pour plus de détails sur les mesures des performances, vous pouvez vous reporter à un récent livre blanc sur VMware.

Meilleures pratiques VMware

VMware a développé un large éventail de meilleures pratiques concernant l'utilisation d'Exchange dans les environnements VMware. Ces meilleures pratiques sont résumées ici. Pour connaître tous les détails, reportez-vous au Guide des meilleures pratiques de Microsoft Exchange 2010 sur VMware.

Meilleures pratiques pour les CPU virtuels (vCPU)

  • Allouez plusieurs vCPU à un ordinateur virtuel uniquement si la charge de travail Exchange prévue peut réellement bénéficier de tous ces vCPU.
  • Si la charge de travail exacte est inconnue, attribuez un plus petit nombre de vCPU à l'ordinateur virtuel au départ et augmentez ultérieurement leur nombre en cas de besoin.
  • Pour les ordinateurs virtuels Exchange sur lesquels les performances sont stratégiques (notamment pour les systèmes de production), essayez de vous assurer que le nombre total de vCPU attribués à l'ensemble des ordinateurs virtuels est inférieur ou égal au nombre total de cœurs de l'ordinateur hôte ESX.

Meilleures pratiques pour la mémoire virtuelle

  • Ne surallouez pas la mémoire tant que vCenter™ ne signale pas que l'utilisation continue est en deçà de la quantité de mémoire physique du serveur.
  • Définissez la réservation de mémoire sur la taille configurée de l'ordinateur virtuel, ce qui génère un fichier d'échange vmkernel par ordinateur virtuel de zéro octet. N'oubliez pas que la définition de réservations peut limiter VMotion™.
  • Il est important d'adapter la taille de la mémoire configurée d'un ordinateur virtuel. La mémoire est perdue si les ordinateurs virtuels Exchange n'utilisent pas la mémoire configurée.
  • Activez VMware Distributed Resource Scheduling (DRS) pour vous assurer que les charges de travail sont équilibrées dans le cluster ESX. DRS et les réservations peuvent apporter la garantie que les charges de travail critiques disposent des ressources nécessaires pour un fonctionnement optimal.
  • Pour réduire les échanges de système d'exploitation invité, la taille configurée pour l'ordinateur virtuel doit être supérieure à l'utilisation de mémoire moyenne de l'instance Exchange exécutée au niveau du client. Suivez les instructions de Microsoft en matière de configuration de la mémoire et du fichier de pagination/d'échange des ordinateurs virtuels Exchange.

Meilleures pratiques pour la mise en réseau

  • Allouez des cartes réseau/des réseaux séparés pour VMotion, le trafic de journalisation FT et la gestion de l'accès à la console ESX. Vous pouvez également utiliser le marquage VLAN.
  • Allouez un minimum de deux cartes réseau pour le trafic de production Exchange afin de tirer parti des fonctions d'agrégation de NIC. En règle générale, allouez un minimum de quatre cartes réseau par hôte ESX.
  • Utilisez VMXNET3 : une vNIC paravirtualisée installée avec les outils VMware. L'outil VMXNET3 est optimisé pour les environnements virtuels ; il est conçu pour offrir des performances élevées.
  • Pour prendre en charge les VLAN dans vSphere, le réseau virtuel ou physique doit marquer les cadres Ethernet à l'aide de marqueurs 802.1Q faisant appel au marquage de commutateur virtuel (VST), au marquage d'invité d'ordinateur (VGT) ou au marquage de commutateur externe (EST). Le mode VST est le plus répandu.
  • Suivez les directives de conception de la mise en réseau exposées dans le guide VMworld 2009 session TA2105 : Concepts et meilleures pratiques concernant la mise en réseau virtuelle. Il contient des concepts permettant de gérer efficacement plusieurs réseaux ainsi que la redondance des adaptateurs réseau sur les hôtes ESX.

Meilleures pratiques pour la gestion des ressources et DRS

  • Les hôtes ESX source et cible doivent être connectés au même réseau gigabit ainsi qu'au même stockage partagé.
  • Il est recommandé qu'un réseau gigabit soit dédié à VMware VMotion.
  • L'hôte de destination doit disposer des ressources suffisantes.
  • L'ordinateur virtuel ne doit pas utiliser de périphériques physiques tels que des CD-ROM ou des disquettes.
  • Les hôtes source et de destination doivent posséder des modèles de CPU compatibles. Sinon, la migration avec VMware VMotion échoue.
  • Pour réduire le trafic réseau, il est recommandé de laisser les ordinateurs virtuels communiquant les uns avec les autres (par exemple les boîtes aux lettres et les GC) sur le même ordinateur hôte.
  • Les ordinateurs virtuels disposant de tailles de mémoire inférieures sont plus adaptés à la migration que les ordinateurs présentant de plus grandes tailles.

Meilleures pratiques de stockage

  • Déployez des ordinateurs virtuels Exchange sur un stockage partagé pour utiliser VMotion, la haute disponibilité et DRS.
  • Chemins d'accès multiples de stockage : configurez un minimum de quatre chemins d'accès depuis un serveur ESX vers une baie de stockage (ce qui requiert au minimum deux ports HBA).
  • Créez des systèmes de fichiers VMFS depuis VirtualCenter pour obtenir le meilleur alignement de partition.

Meilleures pratiques pour les performances du stockage NetApp

NetApp a développé des meilleures pratiques supplémentaires concernant l'utilisation d'Exchange 2010 avec le stockage NetApp. Ces pratiques, décrites dans un récent article Tech OnTap ainsi que dans un rapport technique détaillé, incluent les meilleurs moyens de bénéficier des fonctions d'efficacité du stockage NetApp.

Prenons un exemple : l'association de la déduplication NetApp et du provisionnement fin peut générer des économies allant de 40 à 60 % dans les environnements Exchange 2010.

D'autres travaux récents se sont concentrés sur les moyens d'optimiser les performances Exchange avec le stockage NetApp. Lors d'un récent banc d'essai avec Microsoft Exchange 2010, l'ajout du cache Flash a doublé le nombre d'IOPS réussies et augmenté le nombre de boîtes aux lettres prises en charge de 67 %. Ces résultats sont décrits dans l'article TR-3867 : « Utilisation du cache Flash pour Exchange 2010 ».

Comment obtenir la haute disponibilité et comment effectuer la reprise après incident ?


La création de configurations souples de haute disponibilité et de reprise après incident pour Exchange 2010 est en fait beaucoup plus simple et moins coûteuse dans un environnement virtualisé. Les options et la souplesse de protection des données sont plus importantes à tous les niveaux.

Pour configurer la haute disponibilité et la reprise après incident, vous devez tout d'abord comprendre les modifications importantes apportées par Microsoft dans ses options de résilience native pour Exchange 2010.

Pour remplacer les options de résilience de serveur et de données des versions précédentes d'Exchange, Microsoft a mis en œuvre le groupe de disponibilité de base de données (DAG). Le DAG fait appel à la même fonction d'envoi de journaux que la réplication continue des clusters dans Exchange 2007. Un DAG est composé de 2 à 16 serveurs de boîtes aux lettres. Chaque serveur de boîte aux lettres peut contenir une ou plusieurs copies actives ou passives d'une base de données. Chaque base de données possède un statut différent, de sorte qu'un serveur peut héberger des copies de plusieurs bases de données et n'activer que quelques-unes de ces copies à la fois.

Le DAG utilise un nouveau composant Exchange appelé Active Manager. Ce composant simplifie le basculement et la restauration. Dans le cas d'un échec (notamment un échec du stockage sous-jacent ou de la connectivité du stockage), Exchange 2010 « élève » l'une des copies de la base de données au statut actif. Le rôle de boîte aux lettres prend alors en charge la tâche de service des boîtes aux lettres sur cette base de données. Le basculement a lieu en moins de 30 secondes.

Protection contre les échecs localisés

VMware offre un certain nombre de mécanismes permettant de protéger la disponibilité d'Exchange 2010 contre les échecs locaux.

  • La haute disponibilité VMware en elle-même peut protéger contre les temps d'arrêt dus aux dysfonctionnements matériels locaux.
  • L'association de VMware à l'utilisation d'un DAG protège contre les dysfonctionnements matériels et logiciels, tout en réduisant le temps pendant lequel une base de données se trouve en état non protégé par rapport à l'utilisation d'un DAG seul.

Protection contre les échecs sur un site entier

Pour assurer la protection contre les échecs de site, VMware suggère l'association de VMware Site Recovery Manager (SRM) et de la fonction de DAG. Le DAG offre la protection au niveau du site local tandis que la réplication basée sur le stockage telle que NetApp SnapMirror® est utilisée pour garantir la synchronisation entre une installation de reprise après incident et le site principal. NetApp SnapManager® pour Exchange peut offrir une réplication dépendante des applications pour garantir la cohérence. Si la reprise est démarrée au niveau de l'installation de reprise après incident, SRM automatise et accélère le processus de reprise. Des collaborateurs VMware et NetApp ont discuté des détails de la reprise après incident pour les applications Microsoft (dont Exchange) à l'aide de SRM dans le cadre d'une récente Table ronde Tech OnTap.

Architecture de réplication pour SRM avec les logiciels NetApp SnapMirror et SnapManager.

Figure 2) Architecture de réplication pour SRM avec les logiciels NetApp SnapMirror et SnapManager.

Ces méthodes relatives à la haute disponibilité et à la reprise après incident sont entre autres décrites en détail dans le document Microsoft Exchange 2010 sur VMware : options de disponibilité et de reprise.

Meilleures pratiques NetApp

NetApp a établi un certain nombre de meilleures pratiques à bien prendre en compte dans les environnements Exchange utilisant des DAG :

  • Microsoft recommande d'utiliser un minimum de trois copies de chaque base de données de boîtes aux lettres pour limiter les expositions dues aux éventuels échecs de stockage tels que les doubles pannes de disque. NetApp recommande d'effectuer des déploiements sur stockage NetApp à l'aide de RAID-DP®, qui peut protéger contre les doubles pannes de disque tout en réduisant le nombre de copies de bases de données des boîtes aux lettres. Nous recommandons d'effectuer deux copies de chaque base de données de boîtes aux lettres lorsque les copies se trouvent sur RAID-DP.
  • Chaque copie de DAG est à jour et, de ce fait, ne prend pas la place d'une sauvegarde. Afin que les restaurations puissent être instantanées, Microsoft recommande de créer une copie de base de données « de retard » supplémentaire pour permettre des restaurations instantanées jusqu'à 14 jours en arrière. À défaut, NetApp propose SnapManager pour Exchange, qui vous permet de créer des copies Snapshot compactes et de restaurer en fonction d'un point souhaité sans qu'une copie de retard ne soit nécessaire.
  • Le stockage des copies active et passive doit être identique en termes de capacités et de performances.
  • Les copies active et passive doivent être placées dans des volumes séparés.
  • Effectuez des sauvegardes sur l'un des nœuds passifs.

Conclusion

Les taux d'adoption d'Exchange 2010 ont été forts et une grande attention a été portée à la virtualisation. VMware a œuvré à développer une collection étendue de documents de référence et d'autres ressources pour vous aider à réussir la virtualisation d'Exchange 2010. Pour accéder à la collection complète, cliquez ici. Vous y trouverez de nombreuses informations sur la planification de la capacité, le dimensionnement et tout un éventail d'autres sujets.

VMware a également fait d'importants efforts pour tester et développer des solutions Exchange en rapport avec des partenaires importants tels que NetApp. Tech OnTap a présenté un certain nombre de récents articles axés sur la virtualisation d'Exchange et d'autres applications Microsoft. (Consultez l'encadré.) Toute la collection des ressources NetApp est accessible depuis la page Exchange de NetApp.

Communauté NetApp
 Vous avez des remarques à propos d'Exchange 2010 sur VMware avec le stockage NetApp ?

Posez vos questions, échangez des idées et partagez vos points de vue directement en ligne via les communautés NetApp.

Scott Salyer

Scott Salyer
Architecte principal, Microsoft Solutions
VMware

Scott fait partie du groupe de protection des solutions de VMware qui se concentre sur les meilleures pratiques de virtualisation pour les applications d'entreprise Microsoft. Scott travaille chez VMware depuis le mois de mai 2007 et a rédigé un grand nombre des livres blancs Exchange et SQL Server® disponibles sur le site Web des applications stratégiques de VMware. Avant son arrivée chez VMware, Scott a travaillé 11 ans en tant que consultant de services professionnels auprès des clients et a aidé des clients de grande ampleur à concevoir et à déployer des solutions basées sur la virtualisation VMware, les applications Microsoft et la gestion des identités/accès.

 
Explorer