Virtualisation du poste de travail : Le cas de l'université Rennes 2

Transcription

1 Virtualisation du poste de travail : Le cas de l'université Rennes 2 Humberto Duarte Centre de Ressources Informatiques, Université Rennes 2 Place du recteur Henri Lemoal Rennes Mots clefs Virtualisation, poste de travail, VDI, Vmware, clients légers, «broker», «streaming», «provisioning», hyperviseur Résumé Depuis 2 ans le Centre de Ressources Informatiques de l'université Rennes 2 s'est engagé sur la voie de la virtualisation d'une partie de ses postes de travail. L'idée de pouvoir les importer (virtualiser) dans le "datacenter" est séduisante à plus d'un titre : sécurité et mises à jour centralisées, mutualisation des ressources, image système unique, réparations immédiates, banalisation du poste virtuel, etc. Mais, comment importer les postes de travail sans importer leurs problèmes? Grâce à la mise en place d'un écosystème de virtualisation. Cet article présente les différents éléments qui le composent : L'hyperviseur de virtualisation Le broker de session, Les clients légers, Les systèmes de streaming d'os et de provisioning de machines virtuelles Quels sont les écueils à éviter lors de la mise en place et l'exploitation d'un tel système? Quels sont les avantages et inconvénients d'une telle architecture? Sont également présentés les différents type d'accès aux machines virtuelles : via l'ent, les clients légers et les portables en wi-fi. Enfin, nous verrons les perspectives sur l'avenir des technologies de virtualisation des postes de travail : les protocoles d'affichage et les hyperviseurs clients. 1 Introduction Pour installer et maintenir ses postes de travail, le CRI Rennes 2, comme d'autres établissements, utilise la technique de clonage. Elle consiste à dupliquer un disque système à partir d'une image préparée au préalable. Image qui est étroitement liée au matériel utilisé. Avec l'augmentation continue du nombre de machines et l'évolution incessante des matériels, le maintien d une image système unique devenait impossible, ce qui compliquait le travail de notre petite équipe. Des conflits logiciels nous imposaient de multiplier les tests en amont. L ensemble devenait de plus en plus difficile à gérer. Les mises à jour soit de logiciels, soit des correctifs de sécurité ne pouvaient être garanties et déployées dans des délais raisonnables. C'est après l'expérience réussie de la consolidation de nos serveurs avec l'hyperviseur ESX de Vmware que nous avons décidé de virtualiser nos postes de travail. Virtualiser les postes de travail nous permet de casser l'interdépendance «matériel-système d'exploitation» à l'origine de nombreux problèmes de maintenance. Les virtualiser c'est aussi banaliser les installations, centraliser et déléguer leur administration. C'est gérer une seule image système pour un matériel «unique». C'est augmenter la disponibilité des postes. C'est aussi, la possibilité de proposer une image d'un poste de travail via notre ENT (Environnement Numérique de Travail). Mais surtout, c'est une approche différente de celle utilisée pour consolider nos serveurs. Tout au long de cet article nous décrirons l'infrastructure de virtualisation des postes de travail, son architecture et ses composants, les écueils à éviter ainsi que le dimensionnement de principales ressources systèmes. Enfin nous terminerons par un rapide tour d'horizon sur l'évolution de cette technologie. 2.Virtualiser le poste de travail : l'approche Virtualiser un poste de travail c'est l'importer dans la salle machine ou le «datacenter». Son système d'exploitation «client» va s'exécuter sur du matériel de type serveur (serveurs classiques ou lame). Aussi, son processus de virtualisation sera le même que celui employé pour les serveurs, à savoir : - Création d'une instance ou machine virtuelle à l'aide d'un hyperviseur de virtualisation, - Installation, puis exécution du système d'exploitation, - Utilisation La comparaison s'arrête là. Pour pouvoir utiliser un poste de travail virtualisé nous devons répondre à plusieurs questions. Comment associer une machine virtuelle (MV) à un ou plusieurs utilisateurs? Une fois associée, par quels moyens va-t-on la Page 1/9 JRES 2009

2 rendre disponible? C'est bien de l'image de la MV dont il s'agit et non pas la MV et son disque. Faire fonctionner les postes de travail virtuels va poser d'autres types de problèmes. Par exemple, des problèmes de stockage. Chaque poste virtualisé représente une instance, un utilisateur, et chaque instance nécessite de la présence d'un disque système. A la différence des serveurs virtualisés, les postes de travail se comptent par dizaines voir par centaines dans certains cas. L'espace de stockage occupé sera calculé en fonction du nombre de postes virtuels et de la taille des disques système. Autant dire que le système de stockage risque d'être saturé rapidement. Un autre aspect à prendre en compte est celui du «provisioning» des MV. De façon classique, créer une MV sur un hyperviseur comme ESX demande l'utilisation d'assistants de création et d'une interface graphique, multi-fenêtres et multi-clics. Quelques MV peuvent ainsi être créées rapidement mais la tâche se complique et devient «chrono-phage» dès que le nombre augmente. Une autre question importante est celle des mises à jour du système et l'installation des logiciels sur les postes virtuels. D'une part, le fait de «centraliser» les postes va nous permettre de centraliser l'administration. D'autre part, maintenir un poste virtuel est exactement pareil que maintenir un poste physique classique. Chaque image de chaque MV devra donc être traitée indépendamment. Plus le nombre augmente plus les mises à jour deviennent compliquées à traiter. 3.Concevoir l'infrastructure de virtualisation : la méthode Pour poser les bases de la conception de notre infrastructure de virtualisation nous avons cherché à répondre aux questions posées lors de notre approche présentée précédemment. - Comment déterminer le nombre de machines virtuelles (MV) par serveur? - Comment associer et présenter les MV aux utilisateurs? - Comment gérer l'augmentation du stockage dû aux MV? - Comment provisionner les MV? 3.1Comment déterminer le nombre des MV par serveur Une question qui revient souvent quand on parle de virtualisation du poste de travail est celle relative au nombre pouvant être hébergé par serveur. Nous allons donc donner la marche à suivre pour le déterminer Cartographie des applications Elle consiste à identifier les applications pouvant s'exécuter dans un environnement virtualisé. Par exemple, parmi les applications candidates on trouve les suites bureautiques, les navigateurs web, les clients de messagerie, les logiciels de traitement statistiques, certains logiciels de retouche d'image, etc, etc. Les applications de calculs intensifs, de simulation 3D ou de traitement d'images nécessitent une implémentation et une étude particulières Classification des utilisateurs Consiste à dresser un tableau avec les différents types d'utilisateurs. Il est basé sur le nombre et l'utilisation des logiciels ainsi que la charge appliquée au système. Par exemple, nous avons déterminé 3 types d'utilisateurs : léger, moyen et expert. Un utilisateur de type «expert» va, dans notre cas, utiliser en simultané plus de 3 applications d'une suite bureautique, naviguer avec plusieurs onglets ouverts (4 ou plus), utiliser 1 client de messagerie et un autre de type webmail, travailler avec 2 ou 3 applications métier et/ou spécifiques et utiliser un logiciel antivirus Définition d'un «poste type» A partir des observations effectuées sur de postes physiques avec des utilisateurs de type «experts» nous avons déterminé un poste virtuel «type» définit comme suit : Composant Client Estimation CPU 162,5 MHz Mémoire RAM 512 Mo Disque Système 10 Go Page 2/9 JRES 2009

3 3.1.4.Calcul de la densité des MV hébergées par serveur Une valeur théorique, que l'on trouve régulièrement dans la littérature de différents fondeurs, est celle de 8 MV par cœur. En prenant comme base un serveur de type Bi-Pro, dual cœur, avec 24 Go de Ram nous obtenons 2 x 2 x 8 = 32 MV. A partir de notre poste virtuel «type» défini en le besoins en ressources système pour 32 MV seront les suivants : CPU : 162,5 MHz x 32= 5200 MHz ~= 5,2GHz RAM : 512 Mo x 32= 16384Mo ~= 16 Go Disque : 10Go x 32 = 320 Go Réseau : Lien Gigabit nécessaire. Un agrégat de 3 cartes réseau par serveur. Pour ajuster la valeur CPU il faut aussi tenir compte de la puissance de traitement supplémentaire nécessaire à la virtualisation et aussi aux fluctuations de la charge processeur (pics). On appliquera une marge de sécurité de 25%. La nouvelle valeur CPU sera de : CPU= 5,2Ghz + 25%= 6,5GHz. En ce qui concerne la RAM, et tenant compte de son utilisation en réel, la marge de sécurité à appliquer sera de 40%, d'où la nouvelle valeur : RAM= 16Go + 40%= 22,4Go La taille du stockage à prévoir doit aussi être ajustée. Elle sera composée de l'addition des éléments suivants : Disque système Opérations Pause/reprise Pagination Fichiers journaux Total pour une MV Total pour 32 MV 10 Go 512Mo (taille de la RAM) 512Mo (taille de la RAM) 100Mo 11,1 Go 355,2Go La marge de sécurité à appliquer sera de l'ordre de 15%. La nouvelle valeur ajustée pour le stockage de 32 MV sera de : 355,2Go + 15% = 408,48Go. En résumé, un serveur Bi-Pro, dual cœur à 3,6Ghz avec 24 Go de mémoire et 500Go de stockage pourra héberger jusqu'à 32 MV avec 512Mo de RAM chacune. 3.2 Comment associer et présenter les MV aux utilisateurs? Le «broker» ou courtier pour associer Il s'agit du système qui est chargé de mettre en relation les MV fonctionnant dans le «datacenter» et les utilisateurs. Cidessous la liste (non exhaustive) des différentes tâches effectuées par le broker 1 : a) Authentification des utilisateurs auprès des annuaires LDAP et AD de Rennes 2, b) Organisation des MV en groupes ou pools, c) Attribution des MV à partir d'un pool et en fonction du groupe (LDAP ou AD) et des stratégies («policies») définies préalablement, d) Gestion et suivi des connexions et déconnexions, e) Choix du protocole d'affichage à employer, Le CRI Rennes 2 a choisi le produit «Connection Broker» de la société Leostream. Il s'agit d'une machine virtuelle qui a été «CASifiée» et intégrée à notre ENT Le protocole d'affichage et les clients légers pour présenter Grâce au «broker» les MV peuvent être utilisées à partir des équipements finaux à l'aide d'un protocole d'affichage. Par exemple, pour les MV Windows le protocole d'affichage utilisé est RDP (Remote Desktop Protocol) version 6. Pour les MV de type Linux le protocole utilisé est NX (No Machine). Le CRI a choisi d'utiliser des clients légers Wyse, modèle V10L, comme équipements finaux des salles de cours et des bureaux. Ils sont simples à administrer (un serveur FTP suffit), proposent des fonctionnalités multimédia et de connectivité USB avancées et sont compatibles avec notre broker. Pour pouvoir gérer les flux 1 Voir schéma fonctionnel du «broker» en annexe. Page 3/9 JRES 2009

4 multimédias et USB entre la MV et le client léger la société Wyse a développé un agent côté MV et un firmware côté client léger qui communiquent ensemble et gèrent les différents flux de données. 3.3 Comment gérer l'augmentation du stockage dû aux MV? Nous avons calculé que pour 32 MV il nous faut 408,5Go d'espace de stockage. On peut rapidement entrevoir que la saturation de notre système de stockage (SAN) et l'administration de chaque MV vont être les points sensibles de l'infrastructure. Pour régler ces problèmes, nous utilisons la technologie dite de «streaming». La MV va démarrer son système via le réseau, en PXE 2, à partir d'une seule et unique image disque. Ce système sera distribué par ruissellements ou «streaming». Le produit utilisé est «provisioning Server for desktop 3» de la société Citrix. Nos postes de travail virtualisés démarrent sur une seule image, en lecture seule, et chacun n'occupent que 1 Mo du stockage central (taille minimale nécessaire au démarrage en PXE sous ESX). Nous gérons actuellement 3 images système pour l'ensemble de nos postes (400). Il s'agit d'une image pour les salles de cours, une autre pour les bureaux et une dernière pour les formations spécialisées (MV en Chinois, MV avec de logiciels spécialisés, etc, etc...). Au final, le disque système d'une MV est représenté par un fichier NTFS géré par le serveur de «streaming». Le serveur de «streaming», à son tour, est une machine virtuelle dont les différents disques sont des fichiers au format VMFS gérés par l'hyperviseur. Cette encapsulation rend chaque environnement étanche et facilite les sauvegardes Comment provisionner les MV? Pour pouvoir provisionner (créer) rapidement nos postes de travail virtuels, le CRI Rennes 2 à développé une application en perl, basée sur les API 5 du SDK 6 «Vi Perl Toolkit» d'esx. Elle se présente sous la forme d'un serveur Web Apache tournant sous une MV de type Linux Ubuntu. Elle nous permet de faire des commandes détaillées de machines virtuelles et les exécuter soit immédiatement, soit de façon différée. Cette application communique avec le composant «Virtualcenter» et utilise les «templates» ou modèles créés dans l'architecture ESX. 3.5Compléments d'information, la gestion de la mémoire sous ESX Le mécanisme de «pagination transparente» cherche à mutualiser les blocs de mémoire communs à plusieurs MV. Ceci a pour conséquence la diminution de l empreinte du système d exploitation en mémoire. Comme le montre le graphique cidessous la partie en rouge indique la mémoire virtuelle allouée aux quatre MV analysées. Il s agit des postes sous Windows XP avec 1 Go de mémoire chacun. On voit qu après trois minutes de fonctionnement ESX commence à mutualiser les blocs de mémoire communs à tous les postes. La partie grise, privée, représente la mémoire physique allouée aux quatre postes. C'est ainsi que l'hyperviseur va attribuer Voir document JRES 2007 «Réinstallation de postes clients avec PXE et Partimage» G. BORGHESI et C. BOCCHECIAMPE, Université Louis Pasteur 3 Ex produit ARDENCE de la société ARDENCE achetée en 2008 par Citrix. Aujourd'hui intégré dans le produit «Xendesktop» 4 Voir en annexe schéma d'encapsulation de différents systèmes de fichiers 5 Application Program Interface 6 Software Developpement Kit Page 4/9 JRES 2009

5 Mo de mémoire au lieu de 4Go à l'ensemble des postes. Grâce au chargement d'un nombre important de blocs de mémoire identiques, la technique du «streaming» d'os tire pleinement profit du mécanisme de «pagination transparente». 1.L'architecture mise en place et l'accès aux MV L'infrastructure de virtualisation est donc composée d'un hyperviseur, ESX, d'un broker de session, Leostream, des périphériques d'accès, le clients légers Wyse, des serveurs de «streaming» d'os et d'une application-maison de «provisioning». Les fonctionnalités d'esx telles que DRS 7 (distribution de ressources) ou HA (haute disponibilité) ont été implémentées. Parmi les avantages de ce type de modèle on trouve : - Administration centralisée des postes, - Délégation d'administration de tout ou d'une partie de l'infrastructure, - Mutualisation des ressources réseau, CPU, mémoire, stockage, grâce aux pools de ressources gérés par ESX, - Mises à jour rapides et garanties grâce à la gestion des images-système uniques, - Sécurité améliorée grâce aux images-système en lecture seule, - Optimisation de l'utilisation des ressources serveurs grâce à DRS, - Nouvelle organisation du travail avec une gestion à distance via une console. Moins d'installations physiques, - Performances des postes améliorées grâce au matériel serveur sur lesquels ils sont virtualisés, - Protection des données et facilité d'intégration dans un plan de type PRA-PRI, - Déploiement rapide de nouveaux systèmes (Windows 7, Linux), - Banalisation des postes de travail. Comme toute infrastructure celle-ci a ses inconvénients, parmi lesquels : - Maintenance complexe. Plusieurs technologies à mettre à jour «broker», hyperviseur, firmware des clients légers, des serveurs, correctifs des système ESX (hôte) mais aussi invités (windows, linux). - Maîtriser différentes technologies dans plusieurs domaines : SAN, réseau, système, virtualisation, etc, etc... - Peu ou pas de logiciels de «gouvernance» et de surveillance de l'infrastructure. Certains se sont spécialisés sur certaines parties de l'infrastructure (Exemple : Logiciel Vkernel ) - Installations et suivis des serveurs de plus en plus complexes (technologie des serveurs «lame»). Un seul «boîtier» peut rassembler des switchs (réseau et fibres) des composants spéciaux de type KVM (ilo pour HP) ou de la virtualisation de la connectivité (par exemple produit Flex10 HP) Dans notre architecture les MV sont accessibles à partir des clients légers des salles et bureaux (protocole RDP V6), des pc portables personnels via les réseaux wi-fi des campus, et pour finir via notre Environnement Numérique de Travail (ENT). Le schéma ci-dessous montre en détail l'architecture mise en place à l'université Rennes 2 7 Pour l'architecture d'esx et ses fonctionnalités se reporter à l'article du JRES 2007 «Installation d'une architecture VMWare Infrastructure 3 : Bilan et perspectives» A. MIREK Université Lumière Lyon 2 Page 5/9 JRES 2009

6 2.Écueils à éviter et bonnes pratiques : Lors de la mise en place de notre infrastructure de virtualisation, comme dans tout projet, il y a la théorie et les réalités du terrain. Dans cette partie de l'article nous allons décrire les problèmes rencontrés et les solutions appliquées ainsi que les bonnes pratiques à suivre. 1.Problèmes de latence du protocole RDP : Nous avons été confrontés à des micro-coupures du protocole RDP entre les MV et les clients légers. Ce protocole est sensible aux latences supérieures à 150ms. Pour régler ce problème nous avons, sur les MV de type Windows, changé (créé) l'entrée de registre suivante : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Control\TerminalServer\KeepAliveEnable de type DWORD avec une valeur à 1. Le paramètre «KeepAlive» transmet une pulsation à intervalles réguliers permettant la confirmation de la connexion entre la machine virtuelle et le client léger. Il va de pair avec l'augmentation du paramètre de retransmission d'acquittement des paquets TCP/IP appelé «TcpMaxDataRetransmissions». 2.Configuration des systèmes invités (MV) : Comme expliqué précédemment, les MV sont accessibles via un protocole d'affichage. Pour optimiser leur utilisation et la bande passante il est impératif de désactiver tous les effets visuels, graphiques et autres animations. Aussi, il faut envisager l'arrêt des services ou «daemons» inutiles dans un environnement virtualisé, comme par exemple le service de configuration wi-fi ou restauration système. 3.Distribution de charge des protocoles https et services (broker, dns,dhcp,...) : Une bonne pratique consiste à utiliser un répartiteur de charge pour garantir la disponibilité des services tels que DHCP ou HTTPS. La communication entre les clients légers et les brokers se fait en HHTPS. Les MV et les clients légers, lors du démarrage, font appel aux services DHCP, PXE et Tftpboot. Pour augmenter la disponibilité et équilibrer la charge lors de connexions simultanées (début des cours par exemple) nous avons créé un «cluster» de brokers accessible en HTTPS via un répartiteur de charge. Page 6/9 JRES 2009

7 4.Configuration du système de stockage : [1] [2] Pour bénéficier de toutes les fonctionnalités proposées par ESX il est indispensable de disposer d'un système de stockage performant et centralisé (SAN, NAS ou iscsi). Les postes virtualisés une fois en exploitation feront de nombreux accès simultanés sur le système de stockage et en particulier sur les bus Scsi. Ces accès n'ont rien à voir avec ceux effectués par des serveurs virtualisés. Ici il s'agit bien d'un poste = un utilisateur. Voici une petite liste de bonnes pratiques que nous avons appliquées à notre SAN : Créer sur le SAN des LUN (unités logiques) de petite taille (<= 500 Go), Affecter les LUN en fonction de la charge de travail (I/O intensives), Si possible dédier des LUN en fonction des contrôleurs du système de stockage, Affecter un volume VMFS (système de fichier ESX) ou «datastore» par LUN, Ne pas affecter plus de 40 MV par «datastore» ou volume VMFS, Ne pas affecter plus de 4 serveurs ESX physiques par LUN, Si une MV ou un serveur nécessitent un ou des disques de taille > à 50 Go alors il faut envisager l'utilisation de RDM (Raw Device Mapping) qu'est une méthode d'accès direct aux disques via un fichier-pointeur. Conseillé lors de la mise en place des machines virtuelles en «cluster», Vérifier puis modifier si nécessaire le paramètre «queue depth» des cartes fibre HBA des serveurs ESX. Ce paramètre détermine le nombre de commandes actives par LUN à un instant donné. Valeur par défaut 32 mais certaines cartes HBA peuvent être configurés jusqu'à 255!. Au même temps modifier le paramètre Disk.SchedNumReqOutstanding des serveurs ESX en lui donnant les mêmes valeurs que «queue depth». 5.Paramétrages du BIOS des serveurs : Activer, si supporté par le matériel, les fonctionnalités VT de virtualisation matérielle. Aussi penser à activer le multi-threading mais avec précaution. ESX supporte le multi-threading, 6.Paramétrages du BIOS des systèmes invités : Pour optimiser les ressources des MV nous avons modifié le BIOS en désactivant les périphériques inutiles tels que les lecteurs de disquettes, ou les ports séries et parallèle, 7.Utiliser l'agrégat des cartes réseau (NIC «teaming») : Dédier 2 ou 3 cartes réseau par serveur physique au trafic des MV et 2 cartes au trafic d'administration (sous ESX il s'agit du «service console»), 8.Utiliser les pools de ressources sous ESX et les réservations : Dans le souci de mieux répartir l'utilisation des ressources et pour mieux les protéger nous avons configuré et installé des «pools» de ressource. Il s'agit d'une fonctionnalité ESX. Ils nous permettent de compartimenter nos ressources physiques (RAM, CPU) pour des groupes de MV. Par exemple, nos salles de cours se trouvent dans des pools de ressources avec une limite maximale d'utilisation des cycles CPU et taille mémoire. La délégation d'administration est une autre raison d'utiliser les pools. 9.Surveiller les sous-système de stockage : Il est important de surveiller régulièrement le système de stockage soit de façon automatique soit manuellement les paramètres suivants : latence en lecture/écriture,, encombrement, nombre de lectures, écritures, queue depth, etc. dès les premiers signes de baisse de performances penser immédiatement à réorganiser les LUN et les datastores ainsi que les MV qu'y sont hébergées. 10.Outils de surveillance : Un outil indispensable qui fait partie de l'installation du système ESX est esxtop. Pour les gratuits VlogView de chez Xtravirt pour consulter et consolider les fichiers logs des serveurs ESX et Voptimizer Pro pour optimiser le SAN en alignant les fichiers et en faisant un inventaire exhaustif de l'espace de stockage utilisé, 11.Limiter le nombre des VLAN et LUN : Une autre bonne pratique consiste à garder un nombre de VLAN et LUN raisonnable. Le nombre de LUN et VLANS connectés augmentent la charge de l'hyperviseur. 12.Limiter les installations au niveau du service console : Le service console des serveurs ESX est l'interface entre l'administrateur et le vmkernel, l'hyperviseur. Certains logiciels tierce parties préconisent l'installation de sondes ou autres plug-ins au niveau du service console. Ces installations tôt ou tard auront besoin des mises à jour qui risquent de rendre instable ce service. Page 7/9 JRES 2009

8 3.Perspectives Dans ce type d'architecture le protocole d'affichage reste un des enjeux majeurs. C'est lui qui transporte les données entre les MV et les équipements finaux des utilisateurs. Les frappes du clavier, les mouvements de la souris ainsi que le rafraîchissement de l'affichage ne sont pas les seules données. Les périphériques USB (clés, webcam, scanners, graveurs..) utilisent aussi ce protocole. Les protocoles actuels ne permettent pas l'utilisation des applications hautement graphiques ou de 3D. Le développement d'un nouveau protocole plus riche est la prochaine étape à franchir pour les différents acteurs de ce marché. Net2Display ou PcoIP sont peut être les implémentations à suivre de près. Une autre tendance est la conception d'un «hyperviseur client 8». Il s'agit d'une couche de virtualisation, intégrée dans le BIOS des postes clients (portables, PC) qui permettra de faire fonctionner, comme le fait actuellement ESX, des MV ou «appliances». On pourra imaginer un poste de ce type connecté à un réseau local et qui télécharge une MV professionnelle, une autre pour la navigation et une dernière plus personnelle pour les loisirs. Le tout sur le même poste client avec l'avantage de ne pas disposer d'une infrastructure lourde et en profitant de la puissance de la machine locale. 4.Conclusions Ce projet a été pour nous l'occasion de modifier, en profondeur, notre architecture des postes de travail et nos façons de travailler. Il nous a aussi permis d'étoffer notre offre de services ENT en proposant une MV institutionnelle et l'accès à des logiciels coûteux via notre portail. Depuis sa mise en place, en février 2008, plus de personnes ont utilisé les 400 MV mises à leur disposition. Notre réactivité en cas de pannes a été améliorée et notre système de postes de travail est maintenant plus flexible. 5.Annexes 1.Schéma fonctionnel du broker 2.«Streaming» (encapsulation des systèmes de fichiers NTFS, VMFS) 8 http : // http : // http : // Page 8/9 JRES 2009

9 Bibliographie [1] Vmware, Inc Scalable Storage Performance [2] Hal Rosenberg Vmware, Inc Performance Troubleshooting for ESX [3] Vmware, Inc Performance Tuning Best Practices for ESX [4] Vmware, Inc Vsphere ressource Management Guide [5] Vmware Inc, SAN System design and deployment guide [6] Keith McLaughlin, Citrix Synergy 2009 Planning and Implementation of a provisioning High Availabilty solution [7] Irfan Ahmad, Vmware Inc, Vmworld 2007 Fast and easy disk workload characterization on Vmware ESX server Page 9/9 JRES 2009