2011 01-19-20!05!50 note danalysetechnologique br

Dossier dAnalyse Technologique

Les Hyperviseurs serveurs x86Par Bertrand Quillvr, Alcane, partenaire technologique du CRIP Assistance ditoriale : Renaud Bonnet, Dlgu technique du CRIP

Produit par le :

ALCANE est une socit spcialise en architecture technique et en virtualisation globale des infrastructures informatiques (Serveurs + Stockage + Rseaux + Postes de travail + Applications). Elle intervient pour le compte des Directions des infrastructure et de la production de grandes socits pour des missions ayant pour objectifs lamlioration des niveaux de service et la rduction des cots des infrastructures et llaboration puis la mise en uvre de la Roadmap ou feuille de route de linfrastructure. ALCANE a en particulier accompagn 5 membres du CRIP dans la virtualisation de leurs infrastructures reprsentant au total plus de 2000 VM. 20% des membres du CRIP ont dj utiliss les services dALCANE. ALCANE adresse les trois aspects : conomiques, techniques et gouvernance en toute indpendance nayant aucun lien dintrt avec aucun fournisseur et tant rmunr directement par le client final et fournit des prestations de conseil et assistance la matrise douvrage ou la matrise duvre dans les diffrentes phases des projets : Conception, dveloppement, recette, mise en production, production. Nos missions portent le plus souvent sur des systmes dinformations critiques en performance et disponibilit dans de grandes infrastructures Datacenter de plusieurs centaines de serveurs UNIX / Windows. Activits typiques Conception darchitectures techniques globalement virtualises : Serveurs, stockage, rseaux et postes de travail (VDI) et Applications. Conception des architectures de PRA Synchrone/Asynchrone dual site & Grid-Datacenter Etudes de faisabilit de diverses natures (migration, refonte, consolidation de systmes, rduction des cots, analyses de risque, haute disponibilit.) Ralisation de prototypes et maquettes (validation darchitecture, vrification de faisabilit,...) Slection de technologies (slection de fournisseurs, analyse des offres, ...). Etudes techniques de produits (fonctionnalits, performance, robustesse, architecture, volutivit) Conduite dappel doffres : Rdaction du cahier des charges, pilotage de la consultation, analyse des offres, ngociations, assistance la rdaction des contrats. Mise en production (conseil sur la mthode, assistance la mise en uvre) Benchmarking technique de tout types: (Validation de dimensionnement serveurs-stockage-rseaux, Tests de capacit limite, tests de non rgression, comparatifs entre fournisseurs,...) : Spcification des benchmark, mise en uvre et/ou audit de rsultats Bertrand QUILLEVERE Directeur Gnral

EditorialCe dossier danalyse technologique, un nouveau format de document produit par le CRiP lintention de ses adhrents, a pour vocation daider les responsables dinfrastructures et de production dans leur stratgie de mise en uvre de la virtualisation. Il constitue un complment aux travaux conduits depuis maintenant deux ans au sein du Groupe de Travail Virtualisation des serveurs et des postes de travail. Un complment, mais pas un remplacement. Cest le Groupe de Travail Virtualisation qui a demand Bertrand Quillvr de mettre la disposition des membres du CRiP son exprience acquise au cours de nombreuses missions de conseil auprs de grandes entreprises. Il sagit ici de produire un instantan, un tat de lart, sur un lment de technologie prcis. Pour ce faire, le CRiP fixe aux auteurs de ces dossiers le respect dun plan : descriptif fonctionnel prcis de la technologie, tat du march, aperu des volutions attendues, etc. Le tout en respectant bien entendu lindispensable indpendance lgard des fournisseurs. Le lecteur trouvera donc dans ce dossier danalyse technologique des lments de rflexion, mais aussi des outils pratiques daide la dcision, par exemple une grille danalyse fonctionnelle dtaille des diffrents hyperviseurs. Ce dossier na pas la mme dimension que nos Livres Blancs. Ces derniers rendent compte de ce qui nous lie dans nos mtiers : le fait dtre responsables dans la dure des infrastructures, de nous trouver au quotidien en ngociation avec dautres fonctions au sein de nos entreprises, de grer lexistant en mme temps que nous devons adopter les innovations pour amliorer le service rendu par la Production. Il nen constitue pas moins un outil utile pour devenir plus performants dans nos mtiers. Nous vous en souhaitons bonne lecture.

1

Hyperviseurs serveurs x86

Table des Table des Matires Matires des Matires 1 Table Introduction des hypervi2 I Panorama seurs x86 2 1. Dfinition : quest-ce quun hyperviseur, et que fait-il au juste ? 2 2. Courte histoire des hyperviseurs du march en 3 3. Les offres 2010 fonctions avances 4 4. Les dun hyperviseur des four5 5. les stratgies nisseurs 6 5.1 Spcialistes et gnralistes 7 5.2 Certifications,Menaces Tarification des licences, sur le Pratiques 8 II1. lesmodle Open Les diffrentes gnra10 tions dhyperviseurs 11 1.1 Un des back-ends enjeu driv : lvolution propritaires vers x86 Unix promesse de sim12 1.2 La des PRA plification lieux de ladop13 2. tat des tion fin 2010 valuer un 14 3. Comment HV Les questions pratiques 15 4. ? poser se Quel serveur choisir ? 15 5. quelle Densit de VM Avec Acceptable ? calculer son 16 6.? Comment TCO TCO hors services 18 6.1 TCO avec services atta18 6.2 la VM chs Un dtour par les en19 6.3 lectriques jeux TCO : le cot de lhy20 6.4 perviseur pse peuRoI lors 21 6.5 migrationle : Evaluer Physique dune vers Virtuel (P2V) : 7. Bnfices &: Risques 21 22 7.1 Bnfices 22 7.2 Limites Risques 23 7.3III Lvolution : la 4G 24 et au-del 25 Conclusion Histoire des hy26 Annexe I : perviseurs II : Grille dva27 Annexe luation fonctionnelle des hyperviseurs 29Alcane Editorial 1 2 3 Table des Matires I - Panorama des hyperviseurs x862. Courte histoire des hyperviseurs 3. Les offres du march en 2010 1. Dfinition : quest-ce quun hyperviseur, et que fait-il au juste ? 3 3 4 5 56 6

Dossier dAnalyse Technologique : Les

4. Les fonctions avances dun hyperviseur 5. Les stratgies des fournisseurs5.1 Spcialistes et gnralistes

5.2 Certifications, Tarification des licences, Menaces sur le modle Open

II - Les Pratiques

8

1. Les diffrentes gnrations dhyperviseurs1.2 La promesse de simplification des PRA

89

1.1 Un enjeu driv : lvolution des back-ends Unix propritaires vers x86

10

2. tat des lieux de ladoption fin 2010 3. Comment valuer un HV ? 4. Les questions pratiques se poser 6. Comment calculer son TCO ?6.1 TCO hors services

10 11 11 12 1313 14

5. Quel serveur choisir ? Avec quelle Densit de VM Acceptable ?

6.2 TCO avec services attachs la VM

6.3 Un dtour par les enjeux lectriques

15

6.4 TCO : le cot de lhyperviseur pse peu

15

6.5 : Evaluer le RoI lors dune migration Physique vers Virtuel (P2V) 7.1 Bnfices

16

7. Bnfices & Risques7.2 Risques

1616 16

7.3 Limites

17

III - Lvolution : la 4G et au-del Conclusion

17 18 19 27

Annexe I : Histoire des hyperviseurs COMPLMENTSLe CRiP

Annexe II : Grille dvaluation fonctionnelle des hyperviseursLes dossiers danalyse technologique du CRiP

20

27 28

2

En 10 ans, la virtualisation des serveurs x86 a conquis les salles informatiques, devenant un composant essentiel des infrastructures. Les professionnels de la Production se doivent de connatre les caractristiques, les enjeux et les bonnes pratiques de mise en uvre de cette technologie. Ce Dossier prsente les principes de la virtualisation de serveurs x86 ainsi que ltat de loffre en matire dhyperviseurs. Il relve le dcalage entre les capacits de la technologie et la ralit pratique de son adoption. Pour y remdier, il propose des bonnes pratiques, des recommandations, des pistes de rflexion et fournit des indications chiffres des gains financiers conscutifs une migration du physique vers le virtuel. Ce Dossier souligne les ruptures quinduit la monte en puissance des hyperviseurs dans lactivit des services de production, en particulier la ncessit se situer dsormais dans une perspective de conduite du changement matrise et continue. Il propose enfin une grille dtaille dvaluation des hyperviseurs.

I - Panorama des hyperviseurs x86

1. Dfinition : quest-ce quun hyperviseur, et que fait-il au juste ?Un hyperviseur (HV) est un ensemble de codes informatiques capable de faire fonctionner simultanment plusieurs systmes dexploitation sur un mme matriel. LHV, parfois implment sous forme de logiciel embarqu ou de microcode, exerce le niveau de contrle le plus lev sur le matriel. Il permet de crer des machines virtuelles (VM) : des containers logiques offrant un OS exactement les mmes services quun serveur physique : des processeurs (CPU), un jeu de composants (chipset), de la mmoire vive (RAM), des interfaces dentres-sorties (I/O), etc. LHV ralise une abstraction du serveur physique sur lequel il sinstalle : chaque OS voit seulement la machine virtuelle sur laquelle il sexcute, et non pas les particularits du matriel utilis, ni les autres OS. Les OS ignorent quils sexcutent sur une VM, sauf dans les technologies dites de paravirtualisation qui demandent dutiliser une version de systme dexploitation modifie pour mieux prendre en compte son existence virtualise. Afin de faire fonctionner plusieurs instances dOS simultanment sur une mme machine physique, lHV arbitre les requtes entre les diffrentes VM. Il est en raccourci aux OS ce que lOS est aux applications dans un environnement multitches. Il assure le partage des ressources physiques entre VM et doit fournir une qualit de service (QoS) acceptable chaque VM, et mme parfois des QoS diffrencies. Un environnement de virtualisation doit tre dune fiabilit parfaite : un HV ne doit jamais crasher. Bon nombre de Clients ont abord la virtualisation dans lcosystme x86 essentiellement de faon tactique. Pour ces Clients, les enjeux sont : viter lexplosion du nombre de serveurs physiques dans les centres de donnes, diminuer la consommation lectrique et la ncessit de refroidissement, librer de lespace au sein des centres de donnes, augmenter significativement la flexibilit des infrastructures, faciliter le dploiement rapide de nouveaux serveurs, simplifier ladministration des systmes. Ces enjeux se matrialisent davantage au fur et mesure que crot la maturit des diffrentes offres du march. Ladoption de la virtualisation est donc synonyme de rduction des cots. ALCANE a constat chez ses Clients une rduction dun facteur 1,5 3 du TCO (cot total de possession) dune instance Windows (selon le type dhbergement - interne ou externe) sur machine virtuelle par rapport son cot sur matriel physique. Ce chiffre sentend hors cots de transformation du physique vers le virtuel et hors cots dadministration des OS et des applications. A ces lments, sajoutent dautres enjeux trs significatifs : la possibilit de migrer du monde UNIX propritaire backend vers le monde x86, la simplification du Plan de Reprise dActivits (DRP/PRA).

3


Hyperviseurs serveurs x86Dossier dAnalyse Technologique : Les

2. Courte histoire des hyperviseursLes premiers hyperviseurs naquirent sur Mainframes S/360 la fin des annes 60, et continuent tre largement utiliss sous le nom de z/VM. Lhyperviseur assurait alors le partage de ressources systme extrmement coteuses, garantissait un fort niveau disolation entre plusieurs environnements hbergs sur un mme systme physique, et donnait accs un mode interactif et multitches dans un environnement o rgnaient surtout des traitements par lots (batchs). La mini puis la micro-informatique rduisirent ensuite lintrt pour la virtualisation, dautant plus que ces machines cotaient bien moins cher que les mainframes, rendant la puissance de traitement accessible. La virtualisation resta donc une fonction rserve aux systmes haut de gamme. Mais la puissance croissante des processeurs x86 (augmentation des frquences, multi-cur, multithreading, adressage mmoire sur 64 bits, etc.), consquence de la loi de Moore, conduisit disposer dans les salles informatiques de centaines de serveurs dont le taux dutilisation CPU restait souvent sous les 10 %. Il y a l un norme gaspillage. Mme si nombre dutilisateurs nont pas conscience de la sous-utilisation des serveurs physiques. En effet, contrairement aux habitudes des mondes Mainframe ou UNIX, la collecte des informations de taux dutilisation CPU en environnement x86 nappartient pas la culture des administrateurs. Pour remdier cette sous-utilisation de linvestissement matriel, la virtualisation rapparut au tournant des annes 2000, sous limpulsion de VMware. Depuis, quatre gnrations de solutions se sont succdes, conduisant cette technologie du statut de curiosit pour dveloppeurs celui de nouveau modle pour la production informatique. Avec un certain retard, quatre cinq ans, les plates-formes RISC-EPIC/Unix suivirent le mouvement et se dotrent aussi dhyperviseurs. Ce retard explique dailleurs en partie le basculement de nombreux traitement depuis ces systmes RISC-EPIC vers x86 (Windows/Linux).

(Pour plus de dtails voir Annexe I en fin de ce document)

3. Les offres du march en 2010Il existe deux cosystmes diffrents selon la plate-forme prise en charge : x86, objet de ce dossier danalyse technologique ; les systmes RISC-EPIC que nous ne ferons quvoquer. Plates-formes x86-64, processeurs Intel et AMD : VMware avec ESX & VSphere (hyperviseur + outils dadministration), Microsoft avec Hyper-V, Xen, quon retrouve dans les offres commerciales de Citrix (Xen Server), Novell (Suse Linux Enterprise Server, en cours de rachat en septembre 2010), Oracle (OVM x86), KVM, un hyperviseur dsormais intgr officiellement au noyau Linux, quon retrouve dans les distributions Red Hat Enterprise Linux. Ces hyperviseurs prennent tous en charge les OS Windows et Linux. Certains dentre eux grent aussi Solaris x86, les BSD, et des OS plus exotiques ou vieillissants comme Windows NT4. Plates-formes Risc-Epic (Power, Sparc, Itanium) : HP propose HP-VM, un hyperviseur driv de HP-UX et qui quipe ses serveurs Integrity quips des processeurs Itanium dIntel, IBM possde PowerVM, intgr dans les puces Power qui quipent ses serveurs Power Systems, fusionnant les lignes Unix (p Series) et AS400 (i Series), Oracle lors du rachat de Sun a rcupr OracleVM pour SPARC, un hyperviseur embarqu dans une famille de puces Sparc de Sun, les T-3. Ces hyperviseurs prennent en charge les diffrents Unix propritaires de ces constructeurs AIX, Solaris, HP-UX mais aussi OS/400 (System i) pour IBM, OpenVMS pour HP (chez HP), Linux pour tout le monde, et la version de Windows pour Itanium chez HP.

4


Il existe donc au moins 8 hyperviseurs majeurs, grant tous les OS majeurs.

4. Les fonctions avances dun hyperviseurLes hyperviseurs ne se contentent pas dassurer la cration de machines virtuelles. Ils incluent aussi de nombreuses fonctions qui visent rendre le niveau de service dlivr par lenvironnement de virtualisation meilleur que celui obtenu dans un dploiement physique traditionnel. Sans se lancer dans un inventaire exhaustif de ces fonctions, nous en retiendrons 7, les plus critiques. Le redimensionnement dynamique des VM chaud permet dajouter ou de soustraire une machine virtuelle de la mmoire, des processeurs, des disques, des cartes dinterface, et ce sans redmarrage de lOS de la machine virtuelle, sous rserve que les OS invits de la VM acceptent eux aussi ce redimensionnement chaud. La mobilit de machine virtuelle (vMotion chez VMware, LiveMotion chez Xen, Live Migration chez Microsoft) autorise la dplacer dun serveur physique un autre au travers du rseau sans larrter. Cette fonction permet par exemple larrt dun serveur physique pour maintenance sans arrt de service. Toutes les solutions de virtualisation de serveurs rcentes possdent ces fonctions de mobilit, devenues une exigence courante chez les utilisateurs. La virtualisation du stockage procure des fonctions de cration et dadministration de disques virtuels, de thinprovisioning (cration de disques logiques dune capacit excdant lespace physique install), de mobilit des disques virtuels froid ou chaud des fins dadministration ou de haute-disponibilit, de gestion de cartes dinterface FC virtuelles, etc. La virtualisation du rseau, aussi bien celle des interfaces (HBA virtuel) que des quipements eux-mmes (commutateurs virtuels, pare-feu virtuels) qui sexcutent dans des VM et bnficient dun accs privilgi lhyperviseur. La haute-disponibilit assure le dplacement et le redmarrage automatis dun serveur physique source vers un serveur physique cible dune VM qui vient de mourir pour nimporte quelle raison (dlai : quelques secondes quelques minutes). Lquilibrage de charge consiste orchestrer le placement des VM dans un cluster pour optimiser le fonctionnement de lensemble et le respect des rgles de QoS. Relativement matris sur cluster local, il stend dsormais dans des architectures de go-cluster. Le miroir de VM, une fonction rcente, mise en place des fins de rsilience/tolrance de pannes. Deux VM fonctionnent de faon troitement synchronise sur deux serveurs physiques ou au sein du mme serveur, de telle faon que le crash de lune na aucune consquence sur la continuit du service (Remus pour Xen et Fault Tolerance chez VMware.) La multiplication de ces fonctions avances pose question. Lhyperviseur ne risque-t-il pas d aspirer progressivement les fonctions rseau et stockage de la mme faon quil tend se substituer certains mcanismes de haute disponibilit traditionnels (rplication, clusters de scurit) ? On voit apparatre des commutateurs virtuels embarqus dans un hyperviseur, tel le Nexus 1000v de Cisco qui embarque un IOS complet dans un HV. VMware embarque le thinprovisioning directement dans ESX. Demain ce sera le tour de la dduplication ou du chiffrement, de fonctions dadministration avance du stockage, de services de rplication de donnes. Il existe aujourdhui une comptition entre certaines fonctions dlgues des matriels (baies de stockage, quipements rseau, contrleurs de virtualisation) et logiciels spcialiss, et les hyperviseurs.

5



Vous trouverez en annexe II un Questionnaire Fonctionnel Hyperviseur inventoriant plus de 200 fonctionnalits avances pour vous aider dans votre travail de slection. Il est aussi tlchargeable sur le site dITIforums.

5. Les stratgies des fournisseursLa virtualisation des serveurs x86 suscite une profonde recomposition du march informatique dans son ensemble et de la stratgie globale des fournisseurs, bien au-del de la seule brique technologique que constitue lhyperviseur. Ce mouvement se traduit en particulier par une forte tentation pour les acteurs majeurs de reprendre le contrle global des clients par divers moyens que nous allons voquer. Un cran plus loin se profile le modle Cloud, une faon de fournir de linformatique troitement associe la virtualisation, mais dans laquelle linfrastructure devenue service chappe au contrle des directions informatiques. Choisir aujourdhui sa plate-forme de virtualisation ne va pas sans consquences. Se contenter dun hyperviseur nu payant ou gratuit, open source ou propritaire , faire cohabiter plusieurs hyperviseurs, prfrer un package serveurs + rseau + stockage + hyperviseur propos par un consortium de fournisseurs, adopter une offre complte intgrant lapplication ou la base de donnes et fournie par un vendeur unique, autant de choix dont dpendra le niveau de contrle du service informatique sur son infrastructure, mais aussi le niveau de complexit technique et oprationnelle prendre en charge en interne. Il ne faut en aucun cas ngliger cette rflexion, cette prise de conscience des stratgies globales des fournisseurs, et de leurs consquences. Faisons une comparaison. Lors de larrive de la micro-informatique dans les entreprises, les services informatiques ne lont pas prise au srieux. Elle a tout envahi, et les mmes services informatiques ont lutt des annes durant pour en reprendre le contrle. Avec la virtualisation et le Cloud, ce qui chappera au contrle des services informatiques pourrait bien ny jamais revenir.

5.1 Spcialistes et gnralistesBien que les frontires bougent aussi rapidement que les alliances, les fournisseurs se rpartissent aujourdhui en deux familles principales. Les spcialistes ne disposent que dune partie des briques technologiques constitutives dune infrastructure virtualise. Les fournisseurs doffres globales commercialisent des solutions dinfrastructures virtualises compltes, et mme de plus en plus compltes pourrait-on dire. On trouve ici IBM, HP et Oracle-Sun, les trois grands acteurs gnralistes, capables de fournir serveurs, stockage, rseau et logiciels associs sous forme de plates-formes pr-intgres dployer lintrieur des entreprises. Dans ce modle Oracle a choisi depuis le rachat de Sun de dvelopper une offre verticale, en silo, complte, qui part des briques matrielles et va jusquaux applications (SGBD, BI, et demain ERP, CRM, etc.) On peut ajouter ces deux catgories une nouvelle gnration dacteurs qui procurent des plates-formes virtualises sous forme doffres XaaS (PaaS/Platform-as-a-Service, SaaS/Software-as-a-Service, IaaS/Infrastructure-as-aService), comme Google (App Engine), Amazon (EC2 et S3) et de nouveau Microsoft (Azure). Les spcialistes tentent ponctuellement de sallier pour dlivrer une offre complte. En 2009, EMC, VMware (filiale dEMC) et Cisco ont form une coalition fournissant des briques dinfrastructure prconfigures (v-blocks) et des services pour la ralisation de datacenters virtualiss, essentiellement destination dune clientle de trs grands comptes. Plus gnralement, il existe une foule de micro-alliances entre fournisseurs de diffrents composants, qui visent essentiellement certifier le bon fonctionnement des solutions entre elles, et parfois constituer un guichet de maintenance unique assurant au client que ses fournisseurs ne se rejetteront pas la faute en cas de problme. Des offres plus ou moins tendues : Fournisseur Matriel Hyperviseur x86 Logiciels plate-forme* Applications de productivit personnelle et de travail de groupe Applications mtier (PGI, GRC, etc.) Cisco X Citrix X X X X X HP X IBM X Microsoft X X X X X Oracle X X X Red Hat X X VMware X x X

* Systmes dexploitation x86, bases de donnes, serveurs dapplications, etc.

6


5.2 Certifications, Tarification des licences, Menaces sur le modle OpenLa question des certifications apparat comme un puissant moyen de pression des fournisseurs sur les entreprises. Rien de nouveau, certes, mais une exploitation en rgle de ce systme. En effet, la virtualisation peut tre considre comme une nouvelle couche de linfrastructure, qui sajoute celles dj existantes : serveurs, stockage, rseaux, systmes dexploitation, outils dadministration, middlewares, bases de donnes, etc. Cette couche pose des problmes dinteroprabilit, et demande donc une nouvelle vague de certification des matriels comme des applications, occasion dinfluencer les choix de lutilisateur.

Quelques exemples :Microsoft durant quelques trimestres refusait de certifier le fonctionnement de Linux au-dessus de son hyperviseur Hyper-V. Situation rgle depuis, suite un accord crois avec Red Hat. Chez Red Hat, toute application supporte en mode natif le sera aussi en mode virtualis au-dessus de lhyperviseur maison KVM (Kernel Virtual Machine, intgr au noyau Linux). Pour cet diteur, la diffrence entre excution en mode virtuel et excution en mode natif nexiste plus, condition dutiliser son hyperviseur. Chez Oracle, certains logiciels maison ne bnficient pas de certification lorsquils sexcutent sur un hyperviseur VMware. Lditeur se contente alors dun support best effort et demande une recration des bugs en environnement natif pour dvelopper un correctif. Bien entendu, Oracle certifie cependant le fonctionnement de ses applications sur ses propres plates-formes de virtualisation. Autre point stratgique discriminant : la tarification. Il nexiste pour le moment aucun modle tabli concernant les cots logiciels dans les environnements virtuels. De plus ces cots peuvent varier chez un mme fournisseur en fonction de lenvironnement de virtualisation retenu. Oracle consent des tarifs globalement plus avantageux ceux de ses clients qui exploitent sa propre plate-forme de virtualisation qu ceux qui lui prfrent des hyperviseurs concurrents. Oracle pousse de faon gnrale un modle tout-Oracle bien diffrent de la position dun VMware. Les rachats de SpringSource (spcialiste des environnements Java), de Zimbra (suite de collaboration Open Source concurrente dExchange-Outlook de Microsoft), par VMware pourraient dailleurs indiquer une inflexion de la position de ce dernier. Grosse diffrence cependant, VMware ne propose pas de matriel. Au regard de ces volutions, la question se pose : nassistons-nous pas une remise en cause du modle informatique Open tabli depuis deux dcennies avec sa logique de standards, dinterfaces communes et dAPI documentes ? Mme si elle recourt aux matriels les plus emblmatiques de linformatique ouverte les serveurs x86 la virtualisation rinjecte une dose de logique propritaire, en particulier dans la mesure o les problmes dinteroprabilit entre briques techniques se voient rsolus par des offres du type tout-intgr dveloppes par un mme fournisseur, ou un petit groupe de fournisseurs associs. Une attitude qui risque de se traduire par le retour de silos techniques dans les salles informatiques. Dautant plus considrer que les frontires jadis tablies entre serveurs, stockage et rseau se rduisent : les architectures spcialises cdent progressivement le pas lutilisation de plates-formes x86 animes par des systmes dexploitation spcialiss pour la tche fournir. Le gain de puissance continu des puces x86 laisse envisager un avenir dans lequel une plate-forme de stockage saurait aussi abriter des serveurs et assurer des fonctions rseaux, o un serveur physique deviendrait en plus serveur de stockage par simple activation dune machine virtuelle (la chose existe dj avec des solutions comme LeftHand chez HP). Lalliance de lvolution rapide des puces x86 et des hyperviseurs bouscule les frontires traditionnelles entre spcialits. Enfin, la virtualisation sent parfois fort le retour du Mainframe : une garantie de bon fonctionnement acquise au prix dun enfermement auprs dun fournisseur unique. Paul Maritz, le PDG de VMware affirmait en fvrier 2009 lors dune confrence de prsentation de sa solution vSphere Lorsque je parle des gens de plus de 45 ans, je leur explique que nous essayons de construire un mainframe logiciel. . Larry Ellison dOracle avouait suite au rachat de Sun sa fascination pour le modle de ventes de systmes forte intgration qui fit la fortune dIBM dans la priode 65-85.

7


II - Les PratiquesArrive sur le march il y a une dizaine dannes, la virtualisation de serveurs a dj fait lobjet de plusieurs vagues dadoption par les entreprises, conjointement aux volutions des hyperviseurs, mais aussi des processeurs et des serveurs. Aujourdhui, bien implante dans les salles informatiques, lutilisation relle de la virtualisation reste cependant encore trs en-de de ses utilisations possibles. Le 27 septembre 2010, Gartner(1) indiquait dune part que plus de 80 % des entreprises taient engages dans une dmarche de virtualisation, mais dautre part que seulement 25 % des OS sexcuteraient fin 2010 dans une machine virtuelle. Si nous ajoutons cela que 90 % de lactivit serveur actuelle repose sur des systmes x86, nous voyons bien quil existe un problme. Pourquoi ne parvenons-nous pas un taux de virtualisation de 70 %, pourtant aujourdhui raliste en environnement x86 ? Cest quil existe des facteurs dinertie. Tout dabord la difficult percevoir les enjeux et grer le changement : la gestion du changement reste le parent pauvre de linformatique dentreprise, elle chappe par exemple quasiment toujours aux prvisions budgtaires. Lhistoire de linformatique dentreprise montre que le changement se produit sous limpulsion des mtiers ou des directions fonctionnelles, ou encore en rponse lobsolescence technologique, mais toujours de faon contrainte, comme un mal ncessaire plutt que comme un processus naturel. Il sensuit ce que nous appellerons une fracture technologique : le march de la technologie volue plus vite que les clients, qui narrivent plus suivre le rythme de cette volution et se retrouvent confronts une dette technologique croissante. Au fil du temps lcart se creuse entre ce quil serait possible de raliser en partant dune feuille blanche et le rel, ce qui se trouve dans les salles informatiques. Or, la maintenance informatique ne se rduit plus rparer ce qui tombe en panne, mais impose de grer de faon continue le changement pour rester en phase avec ltat des technologies et ne pas devenir obsolte. En effet, hors des murs de lentreprise, se pressent les prestataires de services qui partant dune feuille blanche ou possdant une meilleure gestion de ce changement imposent aux services de production interne de faire sans cesse la preuve de leur comptitivit et de financer leurs changements pour ne pas subir la dette technologique. La situation de retard actuel dans ladoption de la virtualisation dcoule pour partie dun dfaut dinformation et dapprciations obsoltes. De nombreuses estimations primes sont encore prises au pied de la lettre. Par exemple pas plus de 10 machines virtuelles par serveur pour viter les problmes de performances . Un jugement plus du tout en phase avec ltat actuel des techniques. Alors que la troisime gnration dhyperviseurs a dj fait ses preuves, un grand nombre dentreprises continue dbattre de la seconde gnration. Or, comme nous allons le voir, des diffrences significatives les sparent. Mais qui supposent de se tenir dans une dmarche de changement continu.

1. Les diffrentes gnrations dhyperviseursLa monte en puissance des hyperviseurs x86 a eu des consquences significatives sur au moins deux domaines de linfrastructure informatique : Les processeurs intgrrent progressivement des fonctions destines amliorer le fonctionnement de la virtualisation (meilleure gestion des changements de contexte en particulier). Les serveurs x86 saffirmrent comme machines de consolidation. La virtualisation et les plates-formes matrielles dexcution avancent donc ensemble. Les volutions importantes du matriel permettent, au sein dune mme gnration, dobtenir des gains importants en termes de puissance, dutilisation et dligibilit la virtualisation des applications. Nous pouvons dcouper lhistoire des hyperviseurs, et celle de leur adoption, en quatre gnrations :1. Cit par exemple ici http://vmblog.com/archive/2010/09/27/gartner-only-25-percent-of-server-

8

II - Les Pratiques

Gnration 0 (2001-2003) : celle des pionniers, ou early-adopters, qui essayrent les premires gnrations de produits ESX de VMware suite leur mise sur le march en 2001. En 2002, Microsoft racheta Connectrix, un petit diteur de solutions de virtualisation plutt pour postes de travail. Microsoft commercialisa rapidement sous sa marque Virtual Server issu des dveloppements de Connectrix. Lutilisation des hyperviseurs se cantonne alors essentiellement aux oprations de tests-dveloppement. De 1 2 % denvironnements serveurs virtualiss. Gnration 1 (2003-2006) : dclenche par larrive dESX 2.0 de VMware et de vMotion pour le dplacement chaud des VM, cette priode dure jusqu ESX 2.5 compris. On voit alors apparatre Xen, un hyperviseur issu dun projet universitaire open source britannique, rapidement adopt par les diteurs de distribution Linux. Prise en charge de serveurs 4 voies physiques avec processeurs mono-cur par les hyperviseurs. Virtualisation des premiers serveurs frontaux, Web, legacy (NT vieillissants en particulier) et non-critiques. De 2 10 % denvironnements virtualiss. Gnration 2 (2006-2009) : ESX 3.0, Xen 3, OVM x86, Hyper-V de Microsoft. La maturit des hyperviseurs devient manifeste et provoque un grand nombre de dploiements en production et une pntration significative des technologies de virtualisation dans les salles informatiques. Un cosystme de prestataires de services spcialiss se constitue. Les processeurs multi-curs voient le jour et apportent un argument supplmentaire la virtualisation : leur puissance devient difficilement exploitable par les seuls systmes dexploitation excutant des applications faiblement multi-thread. Les processeurs intgrent des instructions pour faciliter le travail des hyperviseurs (Intel-VT et AMD-V). Migration de serveurs de production. De 10 20 % denvironnements virtualiss. Les projets raliss sont gnralement reconnus comme des succs. Gnration 3 (2009-aujourdhui) : le multi-curs se gnralise, les serveurs sont penss pour la virtualisation (quantits importantes de mmoire, grand nombre de curs, optimisation des I/O), la notion de virtualisation des I/O sinstalle. Le processeur Intel Nehalem, un Xeon haut de gamme, apporte un gain de performance denviron 50 % frquence gale par rapport la gnration prcdente. Chez VMware, ESX 4.0 vSphere apporte galement un gain considrable sur la performance par rapport la version 3.5 dESX. Ct hyperviseurs, ce gain tient une rduction massive de la surcharge (overhead) engendre par le traitement de virtualisation des I/Os.Les hyperviseurs, capables de prendre en charge un grand nombre de curs (32 et plus) et de grosses quantits de mmoire (256 Go et plus) deviennent des systmes dexploitation de systmes dexploitation. On assiste alors des migrations de serveurs back-end de type bases de donnes de production, et dapplications lourdes. De 20 40 % denvironnements virtualiss selon ltat davancement des entreprises et selon les zones gographiques.

1.1 Un enjeu driv : lvolution des back-ends Unix propritaires vers x86Les premires phases de virtualisation se droulrent de faon quasi-exclusive plate-forme constante : des serveurs x86 physiques devenaient des serveurs x86 virtuels. Un nouvel enjeu de la virtualisation consiste abandonner le monde Unix propritaire back-end au profit du monde X86. Ce glissement dj entam en mode physique (sans virtualisation, mais par abandon partout o cela est possible des plates-formes RISC-Unix pour passer de simples serveurs x86) devrait sacclrer avec la monte en puissance des hyperviseurs. Dsormais, outre la totale ligibilit de quantit dapplications sur le plan technique, il devient envisageable dabandonner les cosystmes Unix propritaires RISC-EPIC bien installs dans les datacenters depuis une vingtaine dannes. Les parcs de back-end SGBD restent essentiellement composs de machine Unix propritaires : HP, SUN, IBM principalement. Nombre de clients ont dj adopt le systme dexploitation Linux en mode physique en remplacement des Unix propritaires afin de faire massivement baisser les cots. Cependant, peu de Clients ont dj migr leur back-end sur du X86 en mode virtuel. Cette initiative marque une nouvelle tape capitale en termes de consolidation de machines et donc de rduction de cots. La puissance des processeurs x86 rcents, et des machines associes, assure de saffranchir de toute rgression par rapport aux machines propritaires. Le retour sur investissement (ROI) est bien meilleur compte tenu : du cot plus faible des machines des conditions de maintenance des conditions dacquisition des licences (gnralement plus faible sur X86) Alcane constate chez ses client de vraies rflexions autour dune virtualisation globale, incluant la migration des instances UNIX propritaires vers les environnements Linux ou Windows. Cette constation se trouve renforce par la baisse des chiffres de vente des systmes propritaires, particulirement dans le segment du midrange. Cette mme baisse se manifeste dans le monde du X86.

9

II - Les Pratiques


Nanmoins, cette dernire rsulte des effets de la consolidation engendre par la virtualisation, car le nombre dinstances serveur dans le monde X86 a, dans le mme temps, fortement augment.

1.2 La promesse de simplification des PRALe centre de donnes virtualis de manire globale et de bout en bout permet une simplification des plans de reprise (DRP), qui deviennent de fait moins coteux. Une virtualisation totale affranchit de ladhrence des workloads avec le matriel. Le fameux 1 pour 1, un serveur pour une application, disparat. Les machines jusque-l consacres au secours dans les DRP perdent leur fonction exclusive ne rien faire dautre quattendre un accident pour tre actives, et deviennent des plates-formes actives pour les environnements de dveloppement ou dintgration. Dans un scnario de virtualisation de bout en bout, il suffit, en cas de bascule des serveurs principaux vers les serveurs de secours, darrter tout ou partie des machines virtuelles non-critiques afin de rutiliser le matriel ainsi libr pour du DRP de backup de production. Dans un mode physique, il est difficile bien que possible doprer de la sorte, et le PRA se montre bien plus coteux, avec des impacts plus importants sur le RTO (Recovery Time Objective : temps avant retour en service) et le RPO (Recovery Point Objective : fentre maximum de pertes de donnes en cas dincident). Avec la virtualisation, schmatiquement, on arrte des machines virtuelles pour en redmarrer dautres. En mode physique, il faut ncessairement rebooter lectriquement les machines et ce, sous rserve davoir mis en uvre pralablement toute une logistique de Dual boot, de connexions SAN et LAN mixtes pour les deux environnements, etc. Par ailleurs, le monde virtuel permet dimplmenter des architectures beaucoup plus pertinentes pour les situations de rsistance aux incidents : les architectures dites dual site en stretch cluster (double site en cluster tendu). Dans ce modle, le stockage et lhyperviseur fonctionnent en cluster. Le centre de donnes se rpartit sur deux sites gographiquement distants de quelques kilomtres, relis par fibres (20 50 km), et o toutes les instances fonctionnent en mode synchrone. Les donnes sont crites en miroir par un go-cluster de stockage sur les deux sites. La couche de virtualisation prend place au-dessus de ce go-cluster et, de fait, lensemble de linfrastructure fonctionne comme un cluster unique. Lutilisateur possde alors une architecture nativement rsiliente, fonctionnant entre deux sites gographiquement distants, mais la faon dun cluster local. Certains clients utilisent dj ce type darchitecture, toutefois encore trs peu rpandue.


2. tat des lieux de ladoption fin 2010Dans les entreprises franaises, la majorit des clients exploite des hyperviseurs de seconde gnration, mme si le dploiement de la 3G se ralise dsormais, un an aprs son apparition, selon les constats dAlcane qui effectue en 2010 ce type de dploiements. Le taux de virtualisation serait actuellement denviron 25 % 30 % de lensemble des instances OS serveur (chiffres Gartner septembre 2010, voir supra), avec une densit moyenne de 20 VM par serveur. Or le taux dligibilit la virtualisation a franchi les 70 % des serveurs ds 2006 avec le passage la deuxime gnration dhyperviseurs, ce que confirment de nombreux membres du CRiP, et ce taux atteint dsormais 99 % des environnements serveurs. Mme les serveurs de back-end lourds et I/O intensifs sont devenus virtualisables, dans la mesure o cela ne nuit pas leur support par les diteurs. Il existe donc, dans les faits, un fort retard dadoption de la virtualisation ce jour. En considrant que depuis 2006, toute nouvelle instance de systme dexploitation mise en place, que ce soit lors dun nouveau dploiement, dun changement de serveur physique, ou dune volution de gnration dOS, aurait d natre sur un hyperviseur, le taux de virtualisation devrait dj avoir atteint les 75 %. Au lieu de cela nous en restons 25 %-30 %. Plusieurs causes cet tat de fait. Il reste un manque de conscience claire des bnfices lis la virtualisation, ainsi que des possibilits actuelles. La virtualisation a toujours limage dune technologie locale, applicable certaines zones du datacenter, certaines charges, au lieu dtre pense globalement comme une couche transversale de linfrastructure aussi omniprsente que les rseaux, la scurit, la gestion de donnes, etc. Les entits internes en charge des projets applicatifs et mtiers font encore preuve de rticences devant la virtualisation, et continuent demander des environnements physiques jugs plus fiables. Les rsistances et angoisses face au changement, surtout lorsque celui-ci se montre aussi massif, jouent aussi contre ladoption de la technologie grande chelle. La virtualisation en fait les frais comme dautres technologies de rup-

10

II - Les Pratiques

ture avant elle (les environnements ouverts, les serveurs PC, Internet, ). Il existe un dfaut de gouvernance du changement, qui conduit de nombreuses entreprises ne pas mme laborer un plan plus dun an. Les vieux dictons si ce nest pas cass ne le rparez pas, pourquoi changer quelque chose qui marche interdisent de se poser srieusement la question de la rduction des cots conscutive une opration de virtualisation. Enfin, ces rsistances sassocient parfois au dni du devenir-universel de la virtualisation, et ce mme si certaines entreprises ont dj franchi le pas, et imposent lhyperviseur comme socle par dfaut pour tout nouveau projet et toute volution de plate-forme.

3. Comment valuer un HV ?Un hyperviseur sapprcie tout dabord au regard de ses qualits fonctionnelles. Il sagit ici de juger en premier lieu de sa facilit de mise en uvre initiale. Ensuite il faut prendre en compte les lments traditionnels qui valorisent une solution dinfrastructure : outils de supervision et dadministration au quotidien, mthodes de mise jour et de passage de correctifs et de gestion des montes de versions. Ce dernier point parat trs important, car si la virtualisation diminue ladhrence des OS la plate-forme matrielle, lhyperviseur devient le nouveau point dattache entre matriel et logiciel, qui doit assurer plus de souplesse que le couple OS-matriel quil remplace. Ensuite se pose la question de la performance. Elle dictera la densit de VM : le nombre de serveurs capables thoriquement de cohabiter sur un mme hyperviseur. Nous introduirons plus bas la notion de Densit de VM Acceptable, complmentaire de la Densit de VM Possible, mais dicte par des impratifs ne se limitant pas la seule performance. La mesure de performance dun hyperviseur visera toujours tablir le diffrentiel entre le comportement dune application fonctionnant en mode natif, sur un OS directement install sur le matriel, et le comportement de la mme application fonctionnant en mode virtuel, sur un OS install sur un hyperviseur, et cohabitant avec dautres OS dans dautres machines virtuelles animes par le mme hyperviseur. Il faut idalement que lhyperviseur prsente le moins dincidence possible sur le comportement des applications. Il faut tablir partir de combien de machines virtuelles htes les performances se dgradent. Dans cette optique, on constate par exemple quun hyperviseur du mme fournisseur prsente des performances nettement amliores en gnration 3 par rapport la gnration 2, ce qui signifie quil peut animer deux, trois ou quatre fois plus de machines virtuelles en assurant la mme fluidit de fonctionnement. Dans ces procdures dvaluation, il ne faut pas se limiter la seule logique conomique et au bnfice tir de la consolidation de plusieurs serveurs physiques en une seule machine. Les cots et les frais de fonctionnement participent aussi de cette dmarche. Elle ne saurait se rduire la seule performance.

(Voir grille dvaluation fonctionnelle en annexe II)

4. Les questions pratiques se poserLadoption de la virtualisation suppose de rpondre une srie de questions : Parmi les serveurs existants, lesquels sont techniquement ligibles la virtualisation ? Quel support fournira lditeur dans le cas o son application fonctionne sur un hyperviseur et non pas en mode natif ? Un OS exotique, lutilisation dun priphrique non-gr par les hyperviseurs, des besoins en entres-sorties trs spcifiques constituent des obstacles tout aussi rdhibitoires que labsence de support dun diteur lorsque son application sexcute dans une machine virtuelle. La question concerne lensemble du stack serveur. Lentreprise compte-t-elle sengager dans une stratgie mono ou multi-hyperviseurs ? La rsistance de certains diteurs, les spcificits de lexistant, les comptences des quipes en place, imposent parfois dexploiter plusieurs plates-formes de virtualisation. Comment effectuer le passage du physique vers le virtuel : en une fois (mode Big Bang), ou au fil de leau ? Cette dcision dpend des situations de chaque entreprise, et demande un calcul de RoI comme nous le verrons plus bas. Quels serveurs choisir (deux, quatre, huit voies, avec quelle quantit de mmoire, quel type de stockage associ, etc.), avec quelle densit de VM et quelle taille de clusters ? Faut-il isoler ou mutualiser environnements de production et de non-production ? Les mutualiser a lavantage dviter de placer un trop grand nombre de machines de production sur un seul serveur physique. Ainsi, en cas de panne matrielle, toute la production ne tombe pas en mme temps. Quel rseau et quel stockage choisir ? On peut ds maintenant typer ces sous-systmes pour mieux les adapter

11

II - Les Pratiques


aux besoins de la virtualisation. Comment sauvegarder ses machines virtuelles ? Cette question reste complique, et a provoqu lmergence dune foule doutils spcialiss et de mthodes, qui ne rpondent pas toutes aux mmes besoins. Comment provisionner et mastriser les OS sur les VM ? Aujourdhui, beaucoup dentreprises continuent utiliser leurs outils de cration de masters et de dploiement traditionnels. Quelles rgles imposer pour le choix dun dploiement physique ou virtuel aux services utilisateurs ? Comment assurer le refacturation interne des environnements virtuels ? Comment grer les changements au quotidien et le cycle de vie global de sa plate-forme de virtualisation ? En effet, les hyperviseurs voluent rgulirement, comme tous les codes informatiques, ce qui impose des contraintes de mise jour rgulires et de migrations. Comment mettre en place un PRA qui tire au mieux parti de la virtualisation ?


5. Quel serveur choisir ? Avec quelle Densit de VM Acceptable ?En 2010, les serveurs x86 de dernire gnration, alignant 4 voire 8 processeurs 4, 6 ou 8 curs chacun, soit au total des dizaines de curs, possdent une puissance considrable, et donc la capacit datteindre une Densit de VM trs leve. Techniquement, rien ninterdirait dinstaller 200 machines virtuelles ou plus sur un mme serveur physique. Prenons un exemple. Un hyperviseur de seconde gnration (ESX 3.5 de VMware) Install sur un serveur Dell PowerEdge 2950, 2 voies, 8 curs, 8 threads, avec 64 Go de RAM, parvient faire fonctionner dans des conditions correctes 33 machines virtuelles en moyenne. Un serveur de gnration suivante, IBM System x3850, 4 voies, 32 curs au total et 64 threads, avec 512 Go de mmoire, dlivre 8 fois plus de puissance. Sa capacit daccueil dpasse largement les 200 machines virtuelles. Une telle densit de VM est-elle raisonnable ? Si la machine tombe en panne, un nombre trs important denvironnements sen trouvera impact. La fiabilit des serveurs X86 a fortement augment au fil du temps. Des clients utilisant ce type de matriels constatent un taux de panne trs faible et ce, depuis plusieurs annes. Nanmoins les MTBF doivent se situer dans la fourchette : 80 000 heures 200 000 heures. Statistiquement, un MTBF de 80 000 heures implique une panne tous les 9 ans. Pour 4 serveurs il se produit statistiquement environ une panne tous les 2 ans. Si le MTBF passe 160.000 heures, une panne tous les 4 ans. En ce qui concerne lhyperviseur, la question de son MTBF se pose galement. Les mesures effectues par ALCANE sur la base installe de ses clients utilisant VMware ESX 3.1 et 3.5 sont excellentes, et les pannes trs rares pour ne pas dire inexistantes. Toutefois le risque dune dgradation lors dune monte de version nest pas exclure. Mme dans le cadre dune infrastructure incluant un serveur de secours disponible pour reprendre la charge, combien de temps sera ncessaire au redmarrage de lensemble des services sur cette nouvelle machine ? En effet, il ne sagit pas seulement de relancer les machines virtuelles et les OS quelles hbergent, mais aussi lensemble des applications, toutes avec un jeu de donnes cohrentes. Une opration de taille lorsquil sagit de plusieurs dizaines dapplications. Lexploitation se montrera-t-elle en mesure de respecter ses SLA dans de telles conditions ? La question se pose dans ces termes : les quipes dadministration en production pourront-elles grer dans des conditions acceptables la panne simultane de 134 machines virtuelles ou plus ? Si cet vnement se produit, il sera ncessaire de grer un nombre trs important dappels au support interne. Intuitivement, la rponse est: Non : ce nest pas raisonnable de mettre autant de VM sur un serveur . Introduisons donc la notion de Densit de VM Acceptable (DVA), qui dfinit combien de VM fonctionneront sur un mme serveur physique de manire bien prserver les conditions du SLA en cas dincident. Cette DVA dpendra des situations spcifiques de chaque entreprise : dlais de remise en marche tolrable en cas dincident, complexit des applications, nombre dapplications sensibles, types darchitectures, proportion entre les environnements de tests-dveloppement et les environnements de production, etc. De plus, mme lorsquil existe des oprations de dplacement automatique de machines virtuelles en cas de panne matrielle, sur un mode de gestion de haute-disponibilit, une intervention manuelle savre souvent ncessaire pour relancer certaines applications. Il faut ds maintenant travailler avec les collgues des applications pour leur demander de prendre en compte dans leurs dveloppements et nouveaux dploiements le redmarrage automatique dune VM en mode HA.

12

II - Les Pratiques

Ce domaine du redmarrage automatique des applications aprs incident se trouve en volution rapide. En effet, les entreprises ont bien compris quil y avait l une limite laccroissement de la densit de VM dans leurs salles informatiques. Et ce problme se renforcera avec les prochaines gnrations de processeurs qui permettront thoriquement de pousser cette densit au-del de 400 machines virtuelles par serveur. En rponse, on voit apparatre des mcanismes logiciels comme le mirroring de VM (deux machines virtuelles fonctionnant en synchronisation complte) ou les clusters applicatifs de machines virtuelles, version moderne et virtualise des clusters applicatifs traditionnels. Il sagit de logiciels capables de constater lapparition dune panne, et de redmarrer sans intervention humaine une application sur un autre serveur physique en grant lensemble des pr-requis (cohrence des donnes, configuration rseau, politiques de scurit ). Symantec a pris pied dans ce domaine avec sa solution ApplicationHA pour VMware. La DVA dtermine aussi les conditions de la mutualisation ou de lisolation des charges production/non-production. Sur les plates-formes de virtualisation, ne pas mettre tous ses ufs dans le mme panier constitue un adage vieillot mais encore bien dactualit. Les clients dALCANE acceptent actuellement un risque calcul de panne simultane de 35 machines virtuelles. En effet, ils ont, sur les conseils dALCANE, partag sur le cluster Global ESX les environnements de production, de dveloppement, de tests, dintgration et de bureautique. Comme une partie des serveurs de type frontaux se trouve en mode rpartition de charge (load balancing), une rgle interdit davoir plusieurs VM load balances sur le mme serveur physique. Certaines VM sont trs autonomes et ne ncessitent aucun prrequis pour leur redmarrage. De fait une solution HA de redmarrage automatique de VM convient parfaitement. Au final le nombre de VM dont le redmarrage pourrait tre potentiellement problmatique se rduit dans ces conditions 4 ou 5, une quantit tout fait grable.

6. Comment calculer son TCO ?Le calcul des cots est peu prs aussi difficile tablir dans le domaine de la virtualisation quailleurs, mais il existe ici de nombreux paramtres prendre en compte et sur lesquels agir.

6.1 TCO hors servicesUne premire approche consiste tablir un TCO (total cost of ownership/cot total de possession) hors service, qui exclut donc toutes les oprations de mise en service et de maintenance dune machine virtuelle, ainsi que tous les cots lis ladministration de lOS install dans la VM. On exprime ici un cot par VM par mois, qui comprend en ralit : hbergement, puissance lectrique, licences des hyperviseurs, frais de stockage des OS, mmoire, chssis. Nous avons retenu un hyperviseur commercial (et non pas un hyperviseur gratuitement utilisable type KVM ou Xen) et pris en compte sa licence et le montant de la maintenance sur 4 ans. Pour llectricit, le datacenter prsente un PUE de 1,5. Nous simulons ensuite plusieurs formats de machines virtuelles, diffrencis par leur taille (RAM, disque, consommation lectrique, consommation CPU, nombre de CPU virtuelles). La plus modeste suffit pour un petit environnement de dveloppement ou lhbergement dune application legacy faiblement sollicite. La plus puissante recevra par exemple une base de donnes de production. On constate que le TCO mensuel varie en proportion directe de la taille de la VM, et que dans ce modle de cot hors services, lhbergement physique des serveurs reprsente une part importante du cot global : environ les deux tiers. Cette information aura une consquence sur le choix de mettre en uvre une stratgie de migration en mode Big Bang ou au fil de leau.

13

II - Les Pratiques


120,00

TCO mensuel VM (hors services) Base NEHALEM-ESX 16 core 2x8 2ghz DDR3 4GB engagement 4 ans120,00Hebergt Elec Hyperviseur Stor.OS

TCO mensuel hors services Serveur Physique "Moyen"

100,00

100,00

80,00

RAM Chassis Serveur

80,00


60,00

60,00

40,00

40,00

20,00

20,00

0,00 XL L M S Moy

0,00 Physique

6.2 TCO avec services attachs la VMPassons prsent un modle plus complet, qui inclut des cots de services. Une machine virtuelle traverse le cycle traditionnel dun item informatique, depuis sa mise en service jusqu sa mise au rebut, en prenant en compte lensemble des modifications intermdiaires : correctifs, mises jour, sauvegarde des configurations, etc. Notre modle ne prend cependant pas en compte les cots propres ladministration des systmes dexploitation et applications excuts dans les VM. On constate alors quun facteur de multiplication variable mais contenu au sein dune fourchette de x1,5 x3 sapplique sur les cots hors services pour obtenir un TCO avec services. Le ratio TCO physique/TCO virtuel dpend fortement du cot et des conditions de lhbergement dune part, et du volume de machines virtuelles de lautre. Plus on a de machines virtuelles, moins la virtualisation cote cher. Au total, le TCO complet dun serveur en mode virtuel atteint de 66% 33% du TCO dun serveur physique.

Co t Total (hors admin OS) par VM et par mois Hypoth ses: VM Moyenne et Infra de 300 VM 160,00SERVICES MCO+Chgt

Co t Total (hors admin OS) par serveur physique moyen y compris services de setup et de d comissionnement 160,00 140,00Services r currents PVI Frais financiers Services initiaux H bergement

140,00INFRASTRUCTURE

120,00 100,00 80,00 60,00 40,00 20,00 0,00 50 100 150 200 250 300 400 500 600 800 1000

120,00 100,00 80,00 60,00 40,00 20,00 0,001

Electricit Hyperviseur Stor.OS RAM Chassis Serveur

14

II - Les Pratiques

6.3 Un dtour par les enjeux lectriquesPour tablir les bnfices de consommation et de facturation lectriques apports par la virtualisation des serveurs, nous effectuons une srie destimations. Les volumes de ventes annuelles de serveurs x86 incitent poser quenviron 1,25 millions de ces quipements se trouvent en service en 2010 en France. Lligibilit la virtualisation concerne 90% dentre eux. Bmol cependant : une grosse partie de ces serveurs se trouve dans des PME ou sur des sites secondaires, seulement un petit tiers se trouverait dans un datacenter, l o leffet de la virtualisation-consolidation se fait le plus sentir sur la consommation lectrique. Business Case lectrique FranceServeur X86 par an Dure de vie Nombre de serveurs actifs Fraction virtualiser Fraction virtualiser Consommation PUE moyen DC Conso induite par un serveur X86 Parc France Consommation annuelle Cot annuel base 10ct/KWh Fraction de la consommation de la France (450 TWh) Rduction de 95% (250w > 15w) 250 000 serveurs 5 ans 1 250 000 90 % 1 125 000 250 2 500 562,5 0,00 Watt Watt Mga Watt TWh

0 M 0,0 %

534 Mga Watt 0 M

Un calcul approximatif montre que la virtualisation assurerait une rduction drastique de la consommation dnergie : jusque 95 % en utilisant des machines capables dhberger 20 VM, ce qui comme nous lavons vu constitue une hypothse basse. Nous voyons se dessiner ici un potentiel de rduction de consommation de plusieurs trawattheures. Et des exemples concrets mettent dj en vidence des conomies de plusieurs mgawatts.

6.4 TCO : le cot de lhyperviseur pse peuUne analyse des cots pour une infrastructure de 300 VM dployes sur un cluster de 9 serveurs biprocesseurs octo-coeurs (16 curs par serveur), 4 Go de mmoire par VM, avec un hyperviseur payant montre que les dpenses les plus importantes ramenes lunit-VM sont dans lordre : les services rcurrents, le chssis, les services initiaux, et en quatrime position les licences de lhyperviseur. Au total, les services initiaux et rcurrents reprsentent 48% de la facture, contre seulement 11% pour lhyperviseur.Ventilation du co t par VM et par mois pour une infrastructure de 300 VM Cluster de 9 serveurs 16 core (2 proc de 8 core) DDR3 4GB - Hyperviseur "Payant"

Services r currents PVI; 31%

Chassis Serveur; 18% Stor.OS; 9%

RAM; 4%Chassis Serveur RAM Stor.OS Hyperviseur Electricit H bergement Services initiaux Frais financiers Services r currents PVI

Frais financiers; 5%

Services initiaux; 17%

Hyperviseur; 11% Electricit ; 2%

H bergement; 4%

15

II - Les Pratiques


6.5 Evaluer le RoI lors dune migration Physique vers Virtuel (P2V)Deux questions se posent concernant la migration. Est-il rentable de passer dun serveur physique un serveur virtuel ? Comment faut-il procder : en mode Big Bang, ou au fil de leau ? Dans le premier cas, il sagit en quelques mois de remplacer tous ses serveurs physiques ligibles la virtualisation par des serveurs virtualiss. Dans le second, la migration se produira loccasion des remplacements de matriel ou des volutions majeures dOS et dapplications. La migration P2V (Physique vers Virtuel) dun serveur Windows cote de 500 1 000 euros. Si lentreprise est hberge lextrieur, le RoI dune dmarche de type Big Bang est atteint en moins de 24 mois du fait de la diminution de la facturation de lhbergeur, consquence du moins grand nombre de machines loger. horizon de 5 ans, il sensuit une forte rduction des cots. Si lentreprise possde un hbergement interne, des salles, un datacenter : le RoI rsultant dune migration massive napparait pas aussi clairement, sauf si lespace rcupr en salle informatique se retrouve aussitt rutilis. Dans tous les cas, virtualiser au fil de leau en profitant des moments de fin de vie du serveur physique ou de lOS, savre une opration rentable. Et il nexiste aucune bonne raison de ne pas le faire.


7. Bnfices & RisquesAu total, si nous rcapitulons les avantages et les inconvnients potentiels dun passage systmatique la virtualisation, nous aboutissons aux deux listes suivantes.

7.1 Bnfices Rduction des cots dhbergement et dlectricit dans des proportions drastiques (de 80 90 %) Division par 2 en moyenne du TCO hors service par instance de systme dexploitation OS, hors cot de migration et hors administration OS et applications Provisionnement acclr des serveurs se traduisant par un gain de ractivit pour les nouveaux dploiements (plus de configuration de serveur physique au coup par coup) Suppression des arrts pour maintenance des matriels grce aux outils de migration de machines virtuelles chaud qui assurent le dplacement dun workload dune machine physique une autre avec une interruption de service minime Mobilit des instances dOS lchelle mtropolitaine facilitant la mise en place darchitectures haute disponibilit Redimensionnement froid ou chaud des ressources : CPU, RAM, Rseau, etc. dune machine virtuelle et quotas de ressources (QOS). Allongement de la dure de vie dOS et dapplications vieillissants (environnements Windows NT 4 par exemple) Nouveaux modles de rsilience cot rduit (haute disponibilit par la cration de VM miroir en remplacement de clusters de scurit) Plan de reprise dactivit plus simple mettre en place, moins coteux, plus fonctionnel, plus facile tester rgulirement

7.2 RisquesLe risque le plus important : que la virtualisation se traduise par une augmentation et non une rduction des cots. Cest un effet du phnomne dsormais connu, de la prolifration des machines virtuelles, ou Server Sprawl. En effet, dans les cots lis un serveur Windows, la plus grande partie revient linfogrance du systme dexploitation lui-mme. Grce la virtualisation, la production informatique peut diviser par deux ou par trois le TCO des couches basses, soit 20 30 % du TCO total dune instance Windows, sans que le cot li lOS ne sen trouve modifi. Or, aprs virtualisation, il devient bien plus facile et rapide de provisionner un serveur. En consquence de quoi les utilisateurs et les projets consomment un plus grand nombre dinstances Windows, ce qui se traduit dans les faits par une augmentation des cots, mme si celui des couches basses du serveur a fortement diminu. Il faut donc viter cette inflation, soit en rglementant svrement les conditions de cration de nouvelles machines virtuelles, soit plus souplement en sachant les refacturer aux utilisateurs. Il apparat ncessaire de mettre en place une gouvernance du cot des machines virtuelles, la mtrique cl surveiller ici tant le nombre dinstances de systmes dexploitation.

16

II - Les Pratiques

Dans les autres risques, relevons : La dgradation du temps de reprise sur incident en cas de trop forte densit de VM sur un serveur physique, et ce sans automatisation des oprations de redmarrage des applications dans une architecture de haute-disponibilit. Le dfaut de prise en compte du renouvellement de la plate-forme de virtualisation dans le modle technique et conomique global. La virtualisation rduit ladhrence des OS au matriel mais introduit une nouvelle couche technologique dans linfrastructure, couche qui volue. Il faut donc anticiper sur les cycles de renouvellement des plates-formes de virtualisation, un point sur lequel les diteurs conservent gnralement un silence pudique, et les budgter. Cela signifie quune partie des rductions de cot obtenues lors dune premire opration de virtualisation iront la gestion des futurs changements. Le dfaut de prise en compte des cots de service de la virtualisation elle-mme.

7.3 LimitesLinteroprabilit des diffrentes plates-formes de virtualisation prsente des limites pour le moment. Rien ne prouve quun monde dhyperviseurs htrognes incompatibles, singeant les mondes propritaires, sera vit dans les prochaines annes. Tous les acteurs actuellement prsents sur le march de la virtualisation de serveurs ne prsentent pas la mme solidit. Parmi les hyperviseurs aujourdhui prsents sur le march, certains risquent de disparatre dans les prochaines annes.

III - Lvolution : la 4G et au-delAvec seulement une dcennie dexistence, il est certain que les hyperviseurs possdent encore une marge damlioration. La quatrime gnration, attendue courant 2012, apportera une rsilience renforce et une gestion plus avance des classes de services. Du ct de la rsilience, hyperviseurs et matriels volueront pour mieux grer les pannes matrielles, reprenant le modle de fonctionnement prventif dj tabli sur grands systmes IBM et grands serveurs RISC-EPIC/Unix. En cas de signes de mauvais fonctionnement dun processeur, de multiplication des erreurs sur une barrette mmoire, lhyperviseur saura dcommissionner chaud la ressource fautive sans arrt de service. Cette gnration dhyperviseurs ne disposera cependant pas encore de procdures efficaces pour le traitement de pannes plus brutales, et agira essentiellement de faon proactive. Les fonctions de haute-disponibilit se renforceront pour garantir le redmarrage automatique des systmes dexploitation et des applications en cas de dplacement dune machine virtuelle dun serveur vers un autre. Cette volution passera par une intgration des services de haute-disponibilit fournis par les hyperviseurs avec la gestion applicative de la fonction cluster, comme par exemple avec le produit ApplicationHA de Symantec. Par son faible cot comme par sa simplicit dadministration, la haute-disponibilit appuye sur les hyperviseurs remplacer les clusters de disponibilit type Microsoft Cluster. Ce point nous reconduit la question de la Densit de VM Acceptable : si les services de haute disponibilit assurent un redmarrage automatique des applications, on pourra augmenter la densit de VM jusqu plusieurs centaines par serveur physique. Sachant quIntel promet pour les prochaines annes des processeurs 80 curs, cette norme puissance risque de rester inutilisable si cette gestion automatique des pannes natteint pas une maturit satisfaisante. Au-del de la haute-disponibilit, la tolrance aux pannes progressera elle aussi grce loptimisation du modle des machines virtuelles fonctionnant en miroir synchrone. Aujourdhui la limitation de ce modle dcoule des limitations des rseaux, puisquil faut la fois une bande passante suffisante et surtout une trs faible latence pour faire fonctionner correctement une architecture de ce type. Il existe aujourdhui des travaux de recherche sur le modle du cluster-on-a-chip (cluster sur une puce) : deux instances serveur totalement identiques et synchronises sexcutent en mme temps dans deux VM installes au-dessus du mme hyperviseur. En cas de dfaillance dune des deux VM, lautre survit sans la moindre interruption. On se dirige vers la prise en compte dans les plates-formes de virtualisation de la notion de classes de services. Pour le moment, il rgne une logique trs homogne : les machines virtuelles se diffrencient par les caractristiques du matriel qui les anime. Demain la diffrenciation sexprimera en termes de rsilience, de type de sauvegarde applicable, dinstallation sur diffrentes qualits de serveurs (frquence processeurs, capacit globale, rsilience RAM), plus ou moins scuriss. Les VM se trouveront ensuite automatiquement dployes sur lenvironnement matriel correspondant.

17


ConclusionLa virtualisation de serveurs x86 nest plus vraiment une option. Elle simpose pour tirer parti de la puissance toujours croissante des processeurs. Ses bnfices directs ou indirects en termes de consolidation, de rduction de cots, de flexibilit, de contribution une plus grande fiabilit et une rsilience simplifie des infrastructures font dsormais lunanimit. Porte lorigine essentiellement par ces objectifs de consolidation et de rduction de cots, la virtualisation de serveurs va devenir rapidement le vecteur de la pntration du Cloud computing sous toute ses formes grce la mobilit et la relocalisation des workloads quelle rend possibles. Associe aux autres axes de virtualisation (poste de travail, rseaux, stockage) elle fait entrer lindustrie informatique dans une nouvelle tape caractrise par une mise en concurrence gnralise de diffrentes options de production informatique au sens large et de nouvelles perspectives de gain de productivit. Le dbat pour les utilisateurs nest donc plus dans le principe dadoption de la virtualisation mais dans les modalits et ltendue de cette adoption. Une gouvernance plus dynamique en particulier de la gestion de changement simpose. La virtualisation ne conduit pas un tat statique, acquis une fois pour toute. Les modles de rsilience voluent rapidement autorisant une plus grande densit de VM par serveur. Des classes de services accompagnes de SLA plus fins pour les machines virtuelles et les applications portes deviennent possibles et trs utiles. Le Cloud va faire passer la virtualisation de lchelle de la machine virtuelle celle de lapplication. Ladoption en continu des innovations devient la condition de la comptitivit de la production informatique dans le contexte dintense concurrence interne/externe qui souvre. Linfogrance externalise dune production informatique ne constitue certes pas un concept nouveau. Mais elle sexerce jusqu prsent dans un contexte extrmement rigide et contraint, car elle se trouve le plus souvent associe un hbergement captif des infrastructures, lorsque linfogrant est galement lhbergeur. La virtualisation tendue au Cloud computing en brisant tous les liens physique/logique et en librant la localisation des moyens de production lchelle dun continent ouvre des perspectives immenses qui vont bouleverser lcosystme dans son ensemble. Les productions informatiques internes des clients vont entrer progressivement en concurrence directe avec les Cloud providers externes minima sur les nouvelles applications utilisant les ateliers de dveloppement rcents, mais aussi potentiellement sur tout type dapplications de lcosystme X86-Windows-Linux. En face, les fournisseurs redfinissent leur positionnement et leurs alliances dans un triptyque : fournisseurs de composants matriels/logiciels, fournisseurs de services de niche et Cloud providers globals. Ce grand bouleversement dbute et va durer de nombreuses annes

18

Annexes

Annexe I : Histoire des hyperviseursConcept dj ancien, la virtualisation de serveurs nat la fin des annes 1960 dans le monde des grands systmes IBM (Mainframes). Le premier systme de virtualisation utilis en production appartient la grande famille des OS CP/CMS (Control Program / Computer Management System) pour System/360 dIBM. Dabord dvelopp comme un projet exprimental open source, et livr sous forme de sources sans support, il rencontra un tel engouement chez les clients de lpoque que le constructeur en fit un produit commercial sous le nom dhyperviseur VM/370 (Virtual Machine) en 1972. On pouvait alors virtualiser des systmes dexploitation de type DOS VSE et autres, mais aussi une autre instance de VM des fins de test et dveloppement. La logique de lpoque tait dassurer le partage de ressources mainframes extrmement coteuses, de garantir un fort niveau disolation entre diffrents environnements hbergs sur un mme systme physique, et de donner accs un mode interactif et multitches l o rgnaient surtout des traitements par lots (batchs). VM existe toujours, et reste trs largement utilis, sous le nom de z/VM. Avec lapparition de la mini puis de la micro-informatique, la virtualisation perdait de sa pertinence, au point de disparatre du paysage durant trois dcennies. En effet, ces machines, bien moins coteuses que les grands systmes qui les avaient prcdes, firent entrer linformatique serveur dans lre du modle : une machine, un systme dexploitation, une application. Il ne faisait pas sens de dcouper en tranches virtualises ces systmes de puissance modeste compars aux mainframes, et de plus penss ds leur naissance pour fonctionner en mode multitches. La consquence en fut une prolifration de ces machines, particulirement des serveurs x86, dans les annes 90. La nouvelle vague de virtualisation apparut en rponse la monte en puissance des processeurs x86, devenus largement surdimensionnes par rapport la consommation effective des applications. Effet de la loi de Moore (qui prdit le doublement du nombre de transistors construits cot constant sur une mme surface tous les dix-huit mois) : les capacits de traitement des puces doublent plus ou moins tous les dix-huit mois. En consquence, une grande partie des cycles CPU disponibles ne sert rien, et ce malgr lvolution des systmes dexploitation et des environnements dexcution (Java, SQL, piles de type LAMP : Linux, Apache, MySQL, PHP, .Net, etc.). De fait, pour multitches quils soient, les OS modernes ne permettent pas de faire fonctionner dans des conditions de scurit, de stabilit, et dadministration suffisantes un nombre important dapplications. Le modle un serveur-un OS-une application a la vie dure. En consquence de quoi, dans lunivers x86 actuel, la consommation CPU plafonne des taux trs faibles, le plus souvent infrieurs 10 %. Sur un systme Unix, on atteint en moyenne 20 % et dans certaines situations rares et particulires de 50 % 80 % (en cas de consolidation pousse), et sur un mainframe les 80 %. Pour remdier cette sous-utilisation de linvestissement matriel, la virtualisation rapparut au tournant des annes 2000, sous limpulsion de VMware. En 2001, deux produits virent le jour chez cet diteur : GSX pour inviter un systme dexploitation lintrieur dun systme dexploitation install directement sur le matriel, et ESX pour installer plusieurs systmes dexploitation directement sur le matriel. ESX simposa rapidement comme le modle des hyperviseurs x86 pour serveurs dentreprise. Depuis, quatre gnrations de solutions se sont succd, conduisant cette technologie du statut de curiosit pour dveloppeurs celui de nouveau modle pour la production informatique. Avec un certain retard, quatre cinq ans, les plates-formes RISC-EPIC/Unix suivirent le mouvement et se dotrent aussi dhyperviseurs. Ce retard explique dailleurs en partie le basculement de nombreux traitement depuis ces systmes RISC-EPIC vers x86.

19

Annexes


Annexe II : Grille dvaluation fonctionnelle des hyperviseursSommaire :1. 2. 3. 4. 5. 6. 7. 8. 9. Niveaux de service globaux disponibilit et reprise Support matriel (serveur/stockage) et systmes dexploitation introprabilit Recommandations gnrales dusage/best practices de lditeur Gestion des processeurs Gestion de la mmoire Stockage disques et SAN Sauvegarde/restauration Rseau LAN Divers/autres fonctionnalits de lhyperviseur


10. Clusterisation de HOSTS/load balancing des VM et haute disponibilit 11. Mcanismes de dplacement chaud des VM 12. Load balancing des VM et fonctionnalits de haute disponibilit 13. Ressources Management/Sharing gestion de performance 14. Administration centralise des HOSTS et supervision 15. Gestion de la scurit, des privilges et des rles

Terminologie & abrviations :HOST: serveur physique utilis par lhyperviseur VM : Machine virtuelle VP : Processeur virtuel (dune VM) Core : CPU dans un chip (mono, dual ou quad) Thread ou LCPU: CPU Logique dans un core multi-thread Vdisk : disque virtuel pour une VM ADS : Arrt de service NEA = Network Ethernet Adapter, adaptateur rseau physique VNEA = Virtual Network Ethernet Adapter, adaptateur rseau virtuel HBA-FC : Carte adaptateur PCI Fibre Channel

20

Annexes

1. NIVEAUX DE SERVICES GLOBAUX - DISPONIBILIT & REPRISE1.1 Causes darrt de service planifies du HOST 1.1.1 Quelles actions ncessitent un arrt de service du HOST ? (NB: prciser en commentaire ou en renvoi les diffrents cas de figure). Remplacement chaud d'une carte PCI-NEA par une carte identique (HW + FW) Remplacement chaud d'une carte PCI-NEA par une carte diffrente (FW diffrent) Remplacement chaud d'un HBA FC par une carte identique (HW + FW) Remplacement chaud d'un HBA FC par une carte diffrente (FW diffrent) Remplacement chaud d'un processeur (si le HW le permet) Patch Hyperviseur Monte de version mineure hyperviseur Monte de version majeure hyperviseur Certaines reconfigurations du LAN ? Si oui lesquelles ? Certaines reconfigurations du STOCKAGE/ SAN ? Si oui lesquelles (ajout de LUN, changement du Zoning, ..) ? Dfragmentation mmoire / cleanup structures internes hyperviseur Une VM dans un status "bloque" avec "power ON" / "power OFF" impossible ou quivalent Autre cas n1: Autre cas n2: Ajoutez dautres lignes si ncessaire 1.1.2 Quelle est la frquence typique d'arrt de service pour les actions suivantes : Patch Hyperviseur Monte de version mineure Monte de version majeure Dfragmentation mmoire / cleanup structure interne hyperviseur 1.1.3 Mthode de masquage des arrts de service planifis dun HOST : Dplacement des VM hostes chaud Dplacement des VM hostes froid Mise en cluster des VM hostes (cluster VM-VM) 1.2 Causes darrt de service planifies dune VM : Quelles actions ncessitent un arrt de service dune VM ? Ajout d'un VP (virtual processor) Ajout d'un Vdisk Ajout d'un VEA Extension / rduction de la taille mmoire Suppression / dtachement d'un Vdisk Ajout d'un lecteur de CD/DVD virtuel Extension de la taille d'un Vdisk (On suppose que le systme d'exploitation sait la grer chaud ensuite) 1.3 Arrts non planifis (panne HW ou SW) dun HOST : Quels sont les types de pannes qui provoquent un arrt non planifi ? NB: tous les quipements "redondables" sont supposs redonds Carte PCI-Ethernet Carte PCI- HBA FC Panne processeur Panne mmoire (DIMM) 1.4 Gestion et reprise suite des arrts non planifis Mthodes de reprise de service des VM stoppes par la panne du HOST Redmarrage manuel VM par VM sur un autre HOST partageant le stockage Redmarrage manuel global de toutes les VM du HOST sur un autre .... Redmarrage automatique des VM sur un autre HOST (unique) Redmarrage automatique des VM sur un groupe de HOST Peut-on bloquer laccs aux VM pendant la phase de reboot de lensemble des VM ? O/N O/N O/N O/N O/N

O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N

Nbre / an Nbre / an Nbre / an Nbre / an O/N O/N O/N

O/N O/N O/N O/N O/N O/N O/N

O/N O/N O/N O/N

21

Annexes


2. SUPPORT MATRIEL (SERVEURS / STOCKAGE) ET SYSTME DEXPLOITATION - INTROPRABILIT2.1 : Informations gnrales :Y-a-t-il une liste limitative de serveurs officiellement supports ? Y a t-il une liste limitative de stockage SAN et NAS officiellement supports ? (si oui la founrir en annexe ou donner URL du site WEB) Les VM sont-elles compatibles (directement oprables) avec un autre moteur de virtualisation (dun autre diteur) ? (compatbilit format vdisk + driver/interfaces) O/N O/N O/N

2.2 OS Windows supports :Merci de prciser les services packs supports et le support des versions 32 bits/ 64 bits dans le champ commentaire, et de fournir en annexe et/ou URL sur la matrice complte des Guest OS supports Windows XP Windows NT 4 Server Windows 2000 Server Windows 2003 Server Windows 2008 Server Windows Vista Windows 7 Enterprise Windows 7 Professionnal Windows 7 Ultimate


O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N

2.3 Modalits de support des logiciels (hors systme dexploitation) :Existe-t-il une liste des diteurs qui supportent en standard la solution de virtualisation ? (si oui la fournir en annexe) Existe-t-il une liste des diteurs qui supportent la solution de virtualisation mais avec un contrat spcifique ? (si oui la fournir en annexe) Existe-t-il une liste des diteurs qui exigent la reproduction dun incident sur une machine physique avant la prise en compte par le support ?

3. RECOMMANDATIONS GNRALES DUSAGE / BEST PRACTICES DE LDITEURQuelle est la fourchette de nombre total de VM recommand pour un HOST 8 cores base de processeur Intel NEHALEM (mini-maxi) ? L'hyperviseur est-il recommand pour une production critique ? L'hyperviseur est-il recommand pour une utilisation de base de donnes Oracle Y-a-t-il des restrictions sur lusage des bases Oracle dans des VM ? L'hyperviseur est-il recommand pour une utilisation d'une base de donnes SQL Server ? Y-a-t-il des restrictions sur l'usage des bases SQL Server dans des VM ? L'hyperviseur est-il recommand pour des applications consommatrices de ressources E/S ? Y-a-t-il des dgradations de performances au cours du temps pour l'hyperviseur ? Y-a-t-il un "Uptime" (dure de fonctionnement) maximum recommand pour l'hyperviseur ? Windows Vista Windows 7 Enterprise Windows 7 Professionnal Windows 7 Ultimate Modalits de support des logiciels (hors systme dexploitation) Existe-t-il une liste des diteurs qui supportent en standard la solution de virtualisation ? (si oui la fournir en annexe) Existe-t-il une liste des diteurs qui supportent la solution de virtualisation mais avec un contrat spcifique ? (si oui la fournir en annexe) Existe-t-il une liste des diteurs qui exigent la reproduction dun incident sur une machine physique avant la prise en compte par le support ? Nbre O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N

4. GESTION DES PROCESSEURSNombre maximal de cores (ou threads ou LCPU) supports pour 1 HOST Support NUMA (NUMA aware) Affinit NUMA node et mmoire pour une VM Nombre maximal de VM virtual machines Mombre maximal de VP (Virtual Proc) par VM Nombre maximal TOTAL de VP (Virtual Proc) Nbre O/N O/N Nbre Nbre Nbre

22

Annexes

5. GESTION DE LA MMOIRECapacit RAM maximale du HOST supporte Capacit RAM maximale des VM (Windows) Support RAM-DIMM mirroring ou RAID ou Rank Sparing Mcanisme logiciel Hyperviseur de tolrance des pannes mmoire Mcanisme de partage de segment de code mmoire "read only" mode dclaratif Mcanisme de partage de segment de code mmoire "read only" mode automatique Support des fonctionnalits avances des processeurs (tables de pages, ) Nbre Go Nbre Go O/N O/N O/N O/N O/N

6. STOCKAGE DISQUES ET SAN6.1 Interfaces :Nbre maximal de HBA Fiber Channel Nbre maximal de cartes Ethernet pour iSCSI Support des cartes TOE (TCP offload) Support IO PCI adapter ddi une VM (gestion directe) Si oui support multipathing adapteur virtualis / ddi Nbre Nbre O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N O/N

6.2 Boot de Lhyperviseur :Boot en PXE support ? Boot on SAN FC support ? Boot on SAN iSCSI support ? Boot on SAN SAS support ?

6.3 Fonction de virtualisation IO :Support VSAN tagging Support NPIV pour FC Peut-on court-circuiter l'hyperviseur dans la gestion de NPIV ?

6.4 Stockage des disques des VM :Disque virtuel sous forme de fichier d'un filesystem ? Possibilit de ddier une LUN du SAN (FC ou iSCSI) une VM ? Possibilit de journaliser les IO des vdisk ? Possibilit de snapshot/rollback-Undo sur les disques ? Gestion par l'hyperviseur ? Gestion du thin provisionning dans les Vdisk (par l'hyperviseur) Compression des donnes des Vdisk Cryptage des donnes des Vdisk

6.5 Dduplication des donnes de stockage disqueGestion de la rcupration d'espace suite au "delete" de fichier pour le thin provisionning Support du dplacement froid d'un vdisk d'un stockage un autre (via hyperviseur) Support du dplacement chaud d'un vdisk d'un stockage un autre (via hyperviseur) Y-a-t-il un "Buffer Cache" I/O pour les disques, gr par l'hyperviseur ? Si oui la taille du cache est-elle rglable ? Le "Buffer Cache" IO est-il utilis pour les critures ? Support iSCSI comme stockage de Vdisk ? Support NFS comme stockage de Vdisk ? Support CIFS comme stockage de Vdisk ?

6.6 Boot des VMLes VM peuvent-elles booter en PXE ? Les VM peuvent-elles booter en iSCSI ? Les VM peuvent-elles booter sur une LUN du SAN FC ?

23

Annexes


7. SAUVEGARDE / RESTAURATION7.1 Sauvegarde des VM par lhyperviseur :Y-a-t-il des mcanismes de sauvegarde centralise des VM via lhyperviseur sans installer un agent dans la VM et sans flux de donnes gr par la VM (backup off Vhost) ? Lensemble des questions suivantes de la section 7 ne sappliquent que si ces mcanismes de sauvegarde centralise des VM directement par lHyperviseur, sans agent dans la VM existent. Sinon, lorsque les sauvegardes seffectuent obligatoirement par des agents installs dans les VM, passer la section 8. O/N

7.2 Cibles gres :Ces mcanismes de sauvegarde supportent-t-ils une solution SAN ? Ces mcanismes de sauvegarde supportent-t-ils une solution de stockage NAS ? Ces mcanismes de sauvegarde supportent-t-ils une solution de stockage iSCSI ? O/N O/N O/N O/N O/N O/N O/N O/N O/N


7.3 Caractristiques des sauvegardes :Les machines virtuelles et leurs applications peuvent-elles prendre en compte les oprations de sauvegarde (interface VM - Backup centralis) ? Peut-on faire une sauvegarde / restauration au niveau fichier dans une VM ? (si non : disque virtuel entier seulement) Peut-on faire de la sauvegarde incrmentale ? Peut-on faire de la restauration slective au niveau fichier ? Les solutions de sauvegardes peuvent-elles utiliser du 10Gb/s Ethernet ? Existe-il des solutions de sauvegardes avec dduplication la source dans la VM supportes avec l'hyperviseur ? Si oui lesquelles ?

8. RSEAU LANNombre total Carte PCIE supportes Nombre maxi de cartes Gigabit Ethernet Support de cartes 10Gb/s Ethernet Nombre maxi de cartes 10Gb/s Ethernet Switchs virtuels dans les HOST Disponibilit de switchs virtuels Support VLAN tagging (802.1Q) dans les virtual switchs Support des fonctions SRIOV (Single Route IO Virtualisation) des HBA Ethernet (par exemple INTEL Intel 82576) pour les VM Support du court-circuit de l'hyperviseur avec SRIOV (gestion directe par le guest) Nombre maximal de ports par virtual switch Support du Teaming d'adaptateur rseau en actif/passif Support des fonctionnalits Etherchannel ou quivalent Nbre Nbre O/N Nbre O/N O/N O/N O/N O/N O/N O/N O/N

9. DIVERS / AUTRES FONCTIONNALITS DE LHYPERVISEURSupport clustering VMVM (Microsoft MSCS) Si oui, versions supportes Y-a-t-il des restrictions pour le support de MSCS ? Si oui les dcrire Y-a-t-il des restrictions sur le HW support (si MSCS) serveur/stockage ? Si oui, fournir une liste La clusterisation MSCS VMVM ncessite-t-elle que la VM dispose de LUN ddies du SAN ? Support clustering Virtuel Physique (une VM et un serveur Physique en cluster) Fonction de suspend / freeze d'une VM Toutes les actions d'administrations peuvent-elles tre scriptes ? Linterface dadministration graphique (GUI) permet-elle de gnrer le scripting correspondant aux commandes passes dans cette interface dadministration graphique ? O/N Versions O/N O/N O/N O/N O/N O/N O/N

10. CLUSTERISATION DE HOSTS / LOAD BALANCING DES VM et HAUTE-DISPONIBILITL'hyperviseur dispose-t-il d'une fonctionnalit de Cluster de HOST ? Nombre maximal de HOST (noeuds) par Cluster/Pool Peut-on mettre des HOST ayant des HW diffrents dans un mme cluster ? Dplacement des VM d'un noeud l'autre froid l'intrieur d'un cluster Dplacement des VM d'un noeud l'autre chaud l'intrieur d'un cluster Dplacement des VM d'un noeud l'autre froid d'un cluster un autre cluster Dplacement des VM d'un noeud l'autre chaud d'un cluster un autre cluster Peut-on dfinir des groupes ou des pools l'intrieur d'un cluster pour isoler des types de VM distincts? Linterface dadministration graphique (GUI) permet-elle de gnrer le scripting correspondant aux commandes passes dans cette interface dadministration graphique ? O/N Nbre O/N O/N O/N O/N O/N O/N O/N

24

Annexes

11. MCANISME DE DPLACEMENT CHAUD DES VMDplacement des VM travers un lien rseau Support des liens rseaux 10Gb/s (pour le dplacement) Support d'un paralllisme multi-liens Ethernet (pour le dplacement) Dplacement des VM en passant par le stockage Disque Dplacement incrmental de la mmoire (O) ou global avec freeze complet de la VM (N) Dure de dplacement pour une VM de 2GB mmoire inactive sur Ethernet 1Gb/s Dure de dplacement pour une VM de 2GB mmoire inactive sur Ethernet 10Gb/s Y a-t-il une dure maximale admissible pour le dplacement d'une VM ? Dure maximale d'inaccessibilit de la VM pendant le dplacement Y-a-t-il une notion d'chec possible du dplacement d'une VM ? Si un chec intervient est-il notifi par une alarme utilisable en supervision ? Peut-on interrompre le dplacement d'une VM (action oprateur) ? Peut-on suivre / superviser l'avancement d'un dplacement ? Peut-on suivre / superviser l'ensemble d'un groupe de VM en cours de dplacement ? O/N O/N O/N O/N O/N sec sec sec sec O/N O/N O/N O/N O/N

12. LOAD BALANCING DES VM ET FONCTIONNALITS DE HAUTE-DISPONIBILIT12.1 Caractristiques gnrales du Load Balancing :Existe-t-il des fonctions de LOAD balancing automatique des VM sur un groupe de hosts en cluster. Il s'agit de rpartir la charge des VM sur un pool de Host de manire automatise et dynamique entre les nuds d'un cluster de host. Les particularits HW des hosts (nbre de cores, taille RAM,..) sont-elles prises en compte dans les algorithmes du "Load Balancer" ? Peut-on dfinir des affinits et/ou des prfrences entre VM et hosts ? Peut-on verrouiller des VM sur des hosts ? Peut-on dfinir des rgles dinterdiction de prsence simultane de VM sur un mme host (exemple : 3 serveurs WEB en

2011 01-19-20!05!50 note danalysetechnologique br

Documents