Exchange 2013 : quand Microsoft prône une VM par hyperviseur

Après environ 15 ans de Lotus Notes/Domino comme outil de groupware (et accessoirement de messagerie interne…), la pression extérieure aidant (et les marchés publics aussi), nous avons finalement cédé et sommes passés en fin d’année dernière sur une nouvelle plateforme Microsoft Exchange 2013. La migration a été complexe, vous l’imaginez je pense, car il fallait également récupérer le contenu de plus d’une décennie de messagerie/agenda, assurer la formation de nos utilisateurs aux nouveaux outils etc. … malgré tout, nous avons réussi, à marche forcée, à réaliser ce chantier en seulement 3 mois ! Le choix du tout “Outlook Web Access” nous a aussi facilité la tâche coté accès utilisateur. Mais cela, vous allez le voir, nous a aussi causé bien des soucis depuis. En cause ici, vraisemblablement, le calculateur Microsoft servant d’étalon au sizing d’infrastructures Exchange.

Voici le récit “à la Dallas” de cette année 2015, notre première année de production Exchange …

Sur le papier, tout semblait fonctionner à la perfection, comme souvent : une architecture simple reposant, pour la partie mail, sur DAG de 12 bases de données, elles-mêmes posées sur deux grosses machines virtuelles Exchange/2012R2 capables, normalement, de fonctionner seules pour assumer la production de notre institution (15.000 bals à terme). Concernant l’environnement de virtualisation, il n’était pas concevable de choisir autre chose que VMWare, l’ensemble de notre infrastructure reposant sur ces briques. Pour pouvoir dimensionner correctement ces “monstres” (16 vCPU et 96 Go de RAM chacune), nous avons utilisé le calculateur Exchange : en entrée le nombre d’utilisateurs et leur usage moyen, en sortie le sizing. Notre prestataire partenaire, sur cette affaire, se reposait entièrement sur cet outil et cela paraissait légitime. Nous avons réalisé quelques tests préparatoires complémentaires avec un autre outil Microsoft, “loadgen”, qui confirma la parfaite adéquation de notre environnement aux contraintes Exchange …

Sauf que dans la pratique, nous avons rencontré assez vite quelques problèmes de performance lors de la coupure d’un des nœuds, alors même que la migration n’était pas terminée. C’était en Novembre 2014 et ça commençait mal … Nous avons travaillé avec notre intégrateur pour trouver la cause de ce problème, sans grand succès malheureusement (je vous passe les détails évidemment). Malgré tout, comme, en nominal sur nos deux machines, tout fonctionnait relativement bien, nous avons terminé la migration et au début de l’année 2015, l’ensemble de nos utilisateurs étaient migrés sur la nouvelle production.

Pour autant, tout n’était pas réglé, loin s’en faut, car nous étions incapable de tourner “sur un patte”, malgré le respect des best-practices Microsoft issus directement du calculateur officiel. S’en est suivi de nombreux échanges dont je vous passe la teneur plus ou moins en mode patate chaude. Toujours est-il qu’en Mars 2015, nous sommes arrivés à la conclusion qu’avant de pouvoir réellement impliquer l’éditeur de Redmond, il fallait être “à jour” (et là, tout le monde vient de penser devant son écran : comme toujours ! …). Nous avons donc réalisé, laborieusement (et oui, quand on coupait une patte, tous nos utilisateurs étaient quasi bloqués), une mise à jour en CU7, le dernier Cumulative Update d’Exchange en date à cette époque.

Enfin, nous avons commencé à réellement discuter avec Microsoft de nos soucis de performance, malgré le respect des best-practices applicatifs. La encore je vous passe un certain nombre d’échanges un peu “chaud”, pour rester courtois. Nous voici donc en Juin 2015 à préparer volontairement une panne afin de récolter des logs susceptibles de fournir des clefs pour comprendre ce qui n’allait pas. Jusque là, impossible de faire dire à Microsoft si par hasard, notre production était vraiment adaptée à notre usage ; pourtant nous avions fourni les schémas d’architecture et les conclusions du calculateur…

Comble de malchance (Murphy, si je t’attrape), la panne “planifiée” est survenue au moment même où une coupure électrique partielle d’une de nos deux salles a eu lieu, provoquant pas mal de HA… réponse de Microsoft : les logs sont inexploitables car ils sont “pollués” par des éventements extérieurs et ne respectent pas l’ordre des tâches initialement prévues. Notez bien que nous étions PIL dans le cas de figure qui nous préocupait : coupure complète d’un de nos serveurs de production… Bref, après des échanges encore plus musclés, la mort dans l’âme, nous planifions une nouvelle “panne programmée” pour avoir des logs propres, en Septembre 2015.

Pendant ce temps, nous avons évoqué de nombreuses fois en réunion la solution alternative, pragmatique, d’augmenter nos capacités de service en ajoutant de la puissance à notre plateforme Exchange, selon le principe simple : ça marche très bien avec deux machines, mettons-en 4 et nous pourrons donc mécaniquement en couper 1 voir 2 sans que nos utilisateurs n’en pâtissent. Microsoft nous réponds toujours : il faut d’abord trouver la vraie cause avant de pouvoir vous conseiller (en gros). Sur le principe, rien à redire bien sûr, mais dans la pratique, cela faisait donc 1 an quasi jour pour jour que nous avions une production “tendue” et que nous voulions en sortir.

Septembre se passe et nous programmons finalement notre maintenance pour début Octobre. Tout se passe bien cette fois-ci et nous récoltons pas moins de 20 Go de logs, dumps, images mémoire et autre diags VMWare que nous envoyons à notre cher éditeur. Quinze jours se passent et nous voici fin Octobre et la réponse est enfin reçue, laconique, au milieu de 2 pages de graphiques et trois phrases d’explication :
1. Vous ne respectez pas les best-practices VMWare à savoir réservation de mémoire obligatoire et une seule machine virtuelle par serveur (on croit rêver) car il ne faut pas faire d’over-commitment de CPU … mmmmh, bien bien.
2. Augmentez vos capacités de production : ajouter des nouveaux serveurs Exchange
… … … comment ? no comment ?

Pour votre information, voici quelques détails sur cluster VMWare hébergeant les machines. Avant de faire dans l’ironie, il n’existe pas aujourd’hui de contention mémoire ou CPU : les CPU Ready de toutes nos machines hébergées (donc les serveurs Exchange, entre autres) ne montent jamais à plus de 3%, la mémoire totale provisionnée dans les VM est d’un peu plus d’un To pour 3 To physiquement disponibles sur les hosts. Coté hardware, les hyperviseurs de ce cluster sont des machines de guerre (Bi-Xeon E5 2690, 10 Coeurs par CPU avec HT, et au total 6 machines) dont la charge ne dépasse jamais les 20/25% en CPU et 30% en mémoire… bref, le calme plat.

De plus, malgré nos contraintes de plan de secours, nous avions tenté pendant quelques heures de placer les deux machines sur un même hyperviseur physique pour évaluer la contention globale de l’ensemble d’Exchange sur un seul serveur. La encore, calme plat et les deux machines assuraient le service dans les meilleures conditions ! D’autre part, nos machines n’ont pas de réservation mémoire, certes, mais elles n’en ont tout simplement pas besoin … et pour cause, nous nous interdisons l’over-commitment mémoire en interne. Donc, aucun intérêt a priori de forcer chaque machine à avoir sa mémoire réservée. D’autre part, pour la partie CPU, ma règle est que le le CPU Ready global de chaque cluster, globalement, ne dépasse pas les valeurs recommandées par VMWare, à savoir 5%. Nous en sommes loin aujourd’hui.

Tout cela, pour ça ? toute cette énergie pour une réponse banale ? voir triviale ? Les bras m’en tombent. J’ai donc pris le temps de goggler un peu à ce sujet. Après l’avoir fait sur tous les aspects techniques, j’ai orienté cette fois ma recherche sur “la philosophie Microsoft en matière de support” et les rapports – compliqués visiblement – entre VMWare et Redmond au sujet de l’hébergement de plateformes Exchange. Ls infos ne manquent pas, c’est le moins que l’on puisse dire !

En particulier, un billet a attiré mon attention sur Windows IT Pro. Il met en perspective tout ce qui nous est globalement arrivé depuis 8 mois et revient en particulier sur la problématique derrière l’utilisation “dogmatique” des calculateurs de Microsoft. D’un autre coté, VMWare ne déborde pas d’enthousiasme lorsqu’il s’agit de se frotter à Microsoft concernant les best-practices et on en arrive à des situations bien difficiles à gérer, comme résumées dans ce billet, justement.

D’une manière générale, il est vrai que dès que l’on essaye d’obtenir du support spécifique d’un grand éditeur sur ses solutions, alors qu’elles sont hébergées sur des plateformes de virtualisation non “maîtrisées”, le risque de patate chaude est grand. Je pense bien sûr à Microsoft, mais également à Oracle … et ne parlons pas du mode de licensing en environnement virtualisé, proprement scandaleux de certains, suivez mon regard…

Au final, cette affaire nous aura appris une chose : les calculateurs sont là pour établir un cadre, mais il s’agit de ne pas prendre leurs conclusions comme parole d’Evangile, encore plus lorsque la virtualisation est un des élément – crucial – de la chaîne de production.

Je serais très intéressé par vos expériences sur la cohabitation du support Microsoft et VMWare de votre coté ? Ca se passe bien ? Mal ? Vous êtes passé maître en arbitrage de ping-pong ?

Merci pour vos retours !