Démystification de la virtualisation d’Exchange 2010 SP1

Article d’origine publié le mardi 11 octobre 2011

Cela fait quelques mois que nous annonçons des changements majeurs dans nos déclarations de prise en charge de la virtualisation pour Exchange 2010 (Voir Annonce de la prise en charge de la virtualisation matérielle améliorée pour Exchange 2010). Durant cette période, j’ai reçu un certain nombre de questions pertinentes sur des scénarios de déploiement particuliers et sur l’impact des modifications de nos déclarations de prise en charge par rapport à ces déploiements. Compte tenu du grand nombre de questions, il semble opportun de publier des informations et des précisions supplémentaires.

Tout d’abord, un bref rappel des faits. Lorsque nous avons apporté des modifications à nos déclarations de prise en charge, la première chose que nous voulions était de nous assurer que nos clients n’aient pas le sentiment que la disponibilité du service Exchange pouvait être réduite en raison de l’utilisation d’un déploiement virtualisé. En d’autres termes, nous voulions nous assurer que le haut niveau de disponibilité qui peut être atteint avec un déploiement physique d’Exchange 2010 ne serait en aucune façon réduit par un déploiement sur une plateforme de virtualisation. Naturellement, nous voulions également nous assurer que le produit resterait fonctionnel et que les fonctionnalités supplémentaires fournies par la pile de virtualisation ne représenteraient pas un risque de perte de données Exchange pendant une utilisation normale.

Compte tenu de ces points, voici un rapide aperçu de ce que nous avons changé et des conséquences effectives.

Avec Exchange 2010 SP1 (ou version ultérieure) déployé :

• Tous les rôles serveur Exchange 2010, y compris la messagerie unifiée, sont pris en charge dans un ordinateur virtuel.
• Les ordinateurs virtuels de la messagerie unifiée ont les exigences spécifiques suivantes :
  • Quatre processeurs virtuels sont nécessaires pour l’ordinateur virtuel. La taille de la mémoire doit être affectée conformément aux meilleures pratiques standard.
  • Quatre cœurs de processeur physique sont utilisables à tout moment par chaque ordinateur virtuel du rôle de messagerie unifiée. Cette exigence évite tout surabonnement au processeur. Cette exigence affecte la capacité de l’ordinateur virtuel du rôle de messagerie unifiée à utiliser les ressources du processeur physique.
• Les ordinateurs virtuels de serveur Exchange (y compris les ordinateurs virtuels de boîte aux lettres Exchange faisant partie d’un groupe de disponibilité de base de données) peuvent être combinés aux technologies de migration et de clustering de basculement basé sur l’hôte, à condition que les ordinateurs virtuels soient configurés de manière à ne pas enregistrer et restaurer l’état sur disque lors de leur déplacement ou de leur mise hors connexion. Toutes les activités de basculement doivent aboutir à un démarrage à froid lorsque l’ordinateur virtuel est activé sur le nœud cible. Toutes les migrations planifiées doivent soit conduire à l’arrêt et à un démarrage à froid, soit à une migration en ligne qui tire parti d’une technologie telle que la migration dynamique Hyper-V. La migration de l’hyperviseur des ordinateurs virtuels est prise en charge par le fournisseur de l’hyperviseur ; par conséquent, vous devez vous assurer que le fournisseur de l’hyperviseur a validé le test et la prise en charge de la migration d’ordinateurs virtuels Exchange. Microsoft prend en charge la technologie de migration dynamique Hyper-V de ces ordinateurs virtuels.

Examinons quelques définitions afin de clarifier les termes utilisés dans ces déclarations de prise en charge.

• Démarrage à froid : fait référence au démarrage d’un système, de la mise sous tension au démarrage normal du système d’exploitation. Aucun état du système d’exploitation ne persiste dans ce cas.
• État de mise en mémoire : lorsqu’un ordinateur virtuel est mis hors tension, les hyperviseurs ont généralement la possibilité de mettre en mémoire l’état de l’ordinateur virtuel à un point donné dans le temps, de sorte que lorsque l’ordinateur est remis sous tension, il revient à cet état au lieu de passer par un « démarrage à froid ». L’« état de mise en mémoire » est le résultat d’une opération d’enregistrement dans Hyper-V.
• Migration planifiée : lorsqu’un administrateur système entame la migration d’un ordinateur virtuel d’un hôte d’hyperviseur vers un autre, cela s’appelle une migration planifiée. Il peut s’agir d’une migration ponctuelle ou d’une procédure automatisée configurée par un administrateur système et qui vise à déplacer l’ordinateur virtuel selon une indication temporelle ou à la suite d’un événement système autre qu’une défaillance matérielle ou logicielle. Le point clé ici est le suivant : l’ordinateur virtuel Exchange fonctionne normalement et doit être déplacé pour une raison quelconque (cela peut être réalisé via une technologie telle que la migration dynamique ou vMotion). Si l’ordinateur virtuel Exchange ou l’hôte d’hyperviseur contenant l’ordinateur virtuel est confronté à une défaillance, le résultat de cette situation n’est pas « planifié ».

Virtualisation des serveurs de messagerie unifiée

L’une des modifications apportées concerne l’ajout de la prise en charge du rôle de messagerie unifiée sur Hyper-V et d’autres hyperviseurs pris en charge. Comme je l’ai mentionné au début de cet article, nous voulions nous assurer que les modifications apportées à notre déclaration de prise en charge n’affectaient en rien la fonctionnalité du produit et qu’elles offraient le meilleur service possible à nos utilisateurs. Par conséquent, il est indispensable de déployer Exchange Server 2010 SP1 pour la prise en charge de la messagerie unifiée. La raison en est simple. Le rôle de messagerie unifiée dépend d’un composant multimédia fourni par l’équipe de Microsoft Lync. Avant la sortie d’Exchange 2010 SP1, nos partenaires de l’équipe Lync ont mis au point un traitement audio en temps réel de haute qualité dans un déploiement virtuel. Dans la version SP1 d’Exchange 2010, nous avons intégré ces modifications au sein du rôle de messagerie unifiée. Dès lors, nous avons fait quelques tests supplémentaires pour nous assurer que l’expérience utilisateur était aussi optimale que possible et nous avons modifié notre déclaration de prise en charge.

Comme vous le remarquerez, nous avons des exigences spécifiques par rapport à la configuration de l’UC pour les ordinateurs virtuels (et les ordinateurs hôtes hyperviseurs) où la messagerie unifiée est exécutée. Il s’agit d’une précaution supplémentaire pour éviter toute expérience utilisateur médiocre (qui se traduirait par une mauvaise qualité vocale).

Migration et clustering de basculement basé sur l’hôte

Une partie importante de la confusion liée à la modification de la déclaration de prise en charge provient de l’association de la technologie de migration et de clustering de basculement basé sur l’hôte aux groupes de disponibilité de base de données (DAG) Exchange 2010. Ici, les conseils sont très simples.

• Premièrement, abordons la question de la prise en charge ou non des technologies de migration tierces (par exemple vMotion de VMware). Microsoft ne peut pas effectuer de déclarations de « prise en charge » pour l’intégration de produits hyperviseurs tiers qui utilisent ces technologies avec Exchange 2010, car ces dernières ne font pas partie du programme SVVP (Server Virtualization Validation Program) qui couvre les autres aspects de notre prise en charge des hyperviseurs tiers. Nous effectuons ici une déclaration générique de prise en charge mais vous devez vous assurer par ailleurs que le fournisseur de votre hyperviseur prend en charge l’association de sa technologie de migration/de clustering à Exchange 2010. Plus simplement : si le fournisseur de votre hyperviseur prend en charge l’association de sa technologie de migration à Exchange 2010, nous prenons en charge l’association d’Exchange 2010 à cette technologie de migration.

• Deuxièmement, voyons comment se définit le clustering de basculement basé sur l’hôte. Il fait référence à la technologie qui permet de réagir automatiquement aux défaillances de l’hôte et de démarrer les ordinateurs virtuels affectés sur des serveurs de substitution. L’utilisation de cette technologie est bel et bien prise en charge au sein de la déclaration de prise en charge fournie dans le cadre d’un scénario de défaillance, l’ordinateur virtuel démarre à froid sur l’hôte de substitution. Nous voulons nous assurer que l’ordinateur virtuel ne démarre pas à partir d’un état de mise en mémoire persistant sur disque, car il est « obsolète » par rapport au reste des membres du groupe de disponibilité de base de données.

• Troisièmement, en ce qui concerne la technologie de migration évoquée dans la déclaration de prise en charge, nous faisons référence à la technologie qui permet de planifier la migration d’un ordinateur virtuel d’un ordinateur hôte à un autre. Par ailleurs, il peut s’agir d’une migration automatique exécutée dans le cadre d’un équilibrage de charge des ressources (mais sans lien avec une défaillance du système). Les migrations sont bel et bien prises en charge du moment que les ordinateurs virtuels ne démarrent pas à partir d’un état de mise en mémoire persistant sur disque. En d’autres termes, la technologie qui permet de faire migrer un ordinateur virtuel en transportant l’état et la mémoire de l’ordinateur virtuel sur le réseau sans temps d’arrêt observé est prise en charge par Exchange 2010. Notez qu’un fournisseur d’hyperviseur tiers doit assurer la prise en charge de la technologie de migration, dans la mesure où Microsoft assure la prise en charge de l’utilisation d’Exchange dans cette configuration. Dans le cas de Microsoft Hyper-V, cela signifie que la migration dynamique est prise en charge mais pas la migration rapide.

Avec Hyper-V, il est important de noter que le comportement par défaut lors de la sélection de l’opération de migration sur un ordinateur virtuel consiste en fait à effectuer une migration rapide. Pour conserver un état pris en charge avec les membres du groupe de disponibilité de base de données (DAG) Exchange 2010 SP1, il est très important que vous puissiez régler ce comportement comme indiqué dans les paramètres d’ordinateur virtuel ci-dessous (les paramètres affichés ici illustrent le déploiement avec Hyper-V) :

Figure 1 : Comportement d’ordinateur virtuel Hyper-V approprié pour les membres du groupe de disponibilité de base de données

Reprenons. Dans Hyper-V, la migration dynamique est prise en charge pour les membres du groupe de disponibilité de base de données. En revanche, la migration rapide n’est pas prise en charge. Visuellement, voici ce qui est pris en charge :

Figure 2 : Prise en charge de la migration dynamique des membres du groupe de disponibilité de base de données dans Hyper-V (voir la capture d’écran de grande taille)

Et voici ce qui n’est pas pris en charge :

Figure 3 : Aucune prise en charge de la migration rapide des membres du groupe de disponibilité de base de données

Nous espérons que cet article contribuera à clarifier notre déclaration de prise en charge et nos conseils par rapport aux modifications du SP1. Vos commentaires sont les bienvenus.

Jeff Mealiffe

Ceci est une version localisée d’un article de blog. L’article d’origine est disponible à la page Demystifying Exchange 2010 SP1 Virtualization