La virtualisation de Exchange 2007 sur Microsof HyperV

Après un certain nombre d’incertitudes, Exchange 2007 est enfin supporté depuis le SP1 par Microsoft dans sa solution de virtualisation HyperV !
La disparition de ce frein psychologique est maintenant une grande satisfaction pour les entreprises qui souhaitaient virtualiser et aussi par celles qui l’avaient déjà fait.

L’option de tout virtualiser ou presque fait maintenant son chemin et se concrétise dans de nombreuses architectures basées sur cette solution.

Les contraintes

Tout n’est pas virtualisable : Par exemple, le rôle de messagerie unifiée n’est pas supporté par Microsoft. Le support Microsoft n’est pas indispensable pour tous. Néanmoins, à l’usage, on se rend compte qu’à partir d’un certain nombre d’utilisateurs, le service n’est pas réellement exploitable (voix saccadée,…).

Pourtant, HyperV installe une couche de communication réseau permettant aux machines d’émuler une carte réseau à 10 Go qui utilise un bus virtuel (VMBUS), mais cette vitesse est purement interne, entre les différentes machines et la machine hôte.

Par ailleurs, tous les rôles ne se virtualisent pas avec la même facilité !

Il est facile et très intéressant de migrer les rôles CAS (frontal d’accès) et HUB (transport SMTP). La configuration peut facilement être dupliquée, les serveurs peuvent être installés en fonction des besoins, des sites, ce qui apporte une souplesse inégalée.

Les serveurs qui utilisent des espaces disques importants ne sont pas réputés pour être de bons candidats à la virtualisation. Les serveurs de boîtes aux lettres (Rôle MAILBOX) entrent dans cette catégorie. Lorsque le nombre d’utilisateur et la taille des banques d’information restent raisonnables, il n’y a aucun problème à migrer le serveur Mailbox sur HyperV. Plusieurs solutions permettent de lever en grande partie ce problème :

  •      L’utilisation de disque virtuel VHD de taille fixe. Le fait de bloquer l’espace utilisé pour le stockage des bases Exchange permet d’éviter la fragmentation sur le disque du serveur hôte.
    
  •      L’utilisation directe d’un volume (partition) du serveur hôte, qui sera dédié à la machine virtuelle Exchange.
    
  •      L’utilisation de disques iSCSI proposés par Windows Storage Server ou par des baies iSCSI.  L’augmentation croissante des systèmes utilisant le iSCSI pour accéder à des disques distants permet maintenant d’envisager des configurations de toute taille, avec des possibilités de reprises (Avec ou sans cluster) de manière inouïe. La fourniture par Microsoft du composant (Driver) iSCSI initiator dans tous les nouveaux systèmes (Windows 7, Windows 2008 et Windows 2008 R2) facilite largement cette adoption.
    

Les disques iSCSI permettent aussi de dépasser la limite des 2040 GO (2 TO) des fichiers VHD.

Les contraintes spécifiques liées à HyperV et Exchange 2007 sont bien décrites sur le site Microsoft. En revanche, il est important de savoir qu’il ne faut pas utiliser simultanément le clustering de HyperV et le clustering de Exchange 2007. Par ailleurs, l’utilisation des systèmes de captures en temps réel et de migration « live » ne sont pas non plus supportés par Exchange!

Les avantages

La virtualisation permet d’éliminer tous les problèmes liés à juxtaposition de plusieurs logiciels ou fonctions sur un seul ordinateur physique qui parfois ne sont mêmes pas compatibles.

Par ailleurs, la séparation permet de configurer, contrôler et optimiser chaque système en fonction du logiciel installé. L’ensemble permet d’utiliser une machine plus puissante qui profite globalement à toutes les machines, pour une consommation et un encombrement bien moindre.

L’application des patchs s’appliqueront à moins de machine, provoquant moins de redémarrage.

Les calculs à prendre en compte.

Idéalement, le nombre de processeurs alloués aux machines virtuelles ne devrait pas dépasser le double de ceux présents dans la machine hôte. Une machine bi-quad possédant 8 processeurs logiques ne devrait pas gérer plus de 16 processeurs sur l’ensemble des machines virtuelles.

On utilisera le mêmes calculs pour un serveur Exchange virtuel que pour un serveur physique. La taille minimale fonctionnelle tourne autour de 1,5 GO, mais 2 GO sont conseillés quels que soit les rôles définis. Les rôles CAS, HUB et EDGE se contenteront souvent de cette mémoire. Le rôle Mailbox sera lui plus gourmand selon le nombre d’utilisateurs. Le nombre de groupe de stockage (donc des banques) peut lui aussi impliquer de la mémoire supplémentaire (jusqu’à 32 GO), sachant qu’il n’y a plus de gains en vitesse au-delà de 16 GO de mémoire.

**Profil d’utilisateurs **
Recommandations pour le serveur de boîtes

Léger
2 GO plus 2 MO par boîte

Moyen
2 GO plus 3.5 MO par boîte

Lourd
2 GO plus 5 MO par boîte

Très lourd
2 GO plus 5 MO par boîte

Pour des informations détaillées : https://technet.microsoft.com/en-us/library/bb738124.aspx

Cache et IOPS(Nombre d’entrées/sorties) estimés par utilisateur selon son profil utilisateur et son activité de messagerie

**Profil Utilisateur **
Envois/receptions par jour (message moyen d’environ 50 KO)
**Cache de la database par utilisateur **
IOPS estimés par utilisateur

Léger
5 envoyés/20 reçus
2 MO
0.11

Moyen
10 envoyés /40 reçus
3.5 MO
0.18

Lourd
20 envoyés /80 reçus
5 MO
0.32

Très lourd
30 envoyés /120 reçus
5 MO
0.48

Extrêmement Lourd
40 envoyés /160 reçus
5 MO
0.64

Pour des informations détaillées : https://technet.microsoft.com/en-us/library/bb738147.aspx

Le nombre d’opérations d’entrée/sortie permettra d’évaluer le nombre de disques nécessaires pour supporter le pic d’activité des utilisateurs.

Selon les disques utilisés, il sera nécessaire d’utiliser plusieurs disques en RAID5, RAID10 voire plusieurs ensembles afin d’obtenir le niveau d’IOPS nécessaire.

Pour information,

  •      Un disque de 10 KTPM supporte environ 130 IOPS
    
  •      Un disque de 15 KTPM supporte environ 180 IOPS.
    

Dans le cas d’utilisation de disques iSCSI, le trafic disque passera par le réseau. Plusieurs points sont donc à prévoir afin d’optimiser le débit.

  •      Une carte réseau dédiée à la communication iSCSI
    
  •      Un réseau dédié à la communication entre la baie iSCSI et  les différents clients iSCSI
    

La solution iSCSI permet aussi d’envisager des clusters de type CCR ou SCC.

Pour éviter tout risque de congestion du réseau, la communication de chaque machine virtuelle avec ses clients supposera une carte réseau physique qui sera liée uniquement à la machine virtuelle autorisée.

Quelques exemples de solutions

La combinaison la plus classique consiste à installer sur chaque site 2 serveurs HyperV. Cette solution correspond à la sécurité maximale pour les sites principaux.

Chaque serveur HyperV héberge les machines suivantes :

  •      Un contrôleur de domaine (et DNS)
    
  •      Un serveur Exchange 2007 Standard HUB+CAS
    
  •      Un serveur Exchange 2007 Enterprise CCR
    

Cette architecture permet d’obtenir la tolérance de panne par NLB entre les 2 machines CAS+HUB, ainsi que le cluster de type CCR entre les 2 machines Mailbox. On remarquera que seulement 2 machines physiques sont nécessaires.

Dans le cas de sites plus petits, il est possible de n’installer qu’un seul serveur HyperV.

Ce serveur HyperV contiendra :

  •      Un contrôleur de domaine et DNS
    
  •      Un serveur Exchange 2007 HUB+CAS+MAILBOX
    

Les rôles supplémentaires « partages de fichiers », « partages d’imprimantes » pourront être ajoutés dans une machine virtuelle supplémentaire.

Dans tous les cas, ce type de configuration suppose de bien ordonner le démarrage des différentes machines virtuelles. Les serveurs HyperVs, qui doivent faire partie du domaine, devraient trouver un contrôleur de domaine au moment de leur démarrage. Le contrôleur de domaine hébergé n’étant pas accessible, un autre DC/DNS devra être configuré. Si un 2ème DC est hébergé sur le 2ème serveur HyperV, celui-ci sera choisi.

Pour les machines virtuelles, qui seront effectivement utilisées par les clients du site, c’est le contrôleur de domaine hébergé qui doit être utilisé. Un délai de démarrage (d’au moins 4 minutes) sera donc configuré sur tous les serveurs Exchange hébergés, et sur les autres machines virtuelles nécessitant ce contrôleur de domaine. En effet, les principaux services d’Exchange ne démarrent pas si un catalogue global n’est pas trouvé sur le site.

A noter qu’un délai de démarrage doit aussi être configuré sur les serveurs SQL hébergés !

"Retarder le démarrage d'une machine virtuelle sur HyperV"

Pour ce type de services essentiels, le démarrage sera bien entendu toujours en automatique.

Concernant les rôles DC, DHCP, …, ces machines virtuelles peuvent être basées sur la version CORE de Windows 2008. Cette version permet de diminuer notablement la mémoire dédiée à chaque de ces machines. J’ai affecté 256 Mo à un serveur hébergeant les rôles contrôleur de domaine, DNS, DHCP, DFS… et il reste 50 Mo de mémoire physique non utilisée.

Conclusions

Ces solutions font rêver ou réfléchir mais ne laissent personne indifférent. L’écueil principal n’est plus le matériel (serveurs 64 bits), ni la mémoire vive qui n’est plus très chère, mais plutôt le coût des licences nécessaires à l’installation des différents serveurs Windows et Exchange.

La version Enterprise de Windows 2008 qui autorise l’installation de 4 machines virtuelles (Windows standard ou Enterprise), représente souvent le meilleur choix.

La version Standard n’autorise qu’une seule machine virtuelle. Une licence Windows sera nécessaire pour chaque machine virtuelle supplémentaire (sous Windows).

A l’usage, la solution HyperV s’avère très stable et ne provoque que peu d’administration. L’évolution vers la version HyperV R2 devrait encore améliorer la prise en compte de la solution Microsoft de virtualisation dans de nombreuses architectures.