Étude d une architecture évolutive et haute disponibilité pour les postes de travail virtuels

Transcription

1 Étude d une architecture évolutive et haute disponibilité pour les postes de travail virtuels Ziya Aral Jonathan Ely DataCore Software Récapitulatif Ce rapport fournit une analyse d une configuration de postes de travail virtuels réduisant le coût matériel total par poste de travail à environ 32,41 $, infrastructure de stockage comprise. Ce faible coût est obtenu par l utilisation d une configuration comprenant un stockage à double nœud, avec mise en miroir mutuelle et haute disponibilité. Par rapport à de précédentes études vantant les coûts de l infrastructure de stockage d une infrastructure de postes de travail virtuels (VDI), soit de cinquante à quelques centaines de dollars par machine virtuelle, l importance de ces données devient évidente. Ce rapport démontre que les coûts du matériel de stockage perdent toute importance. Fait encore plus marquant : la configuration en question a engendré ce résultat avec 220 postes de travail virtuels reposant sur une simple paire de serveurs économiques. L innovation majeure consiste à cohéberger les systèmes de virtualisation du stockage redondants sur les mêmes plates-formes matérielles que les postes de travail virtuels. Ainsi, il n est plus nécessaire d amortir les contrôleurs de stockage autonomes au coût élevé sur la base de nombreuses plates-formes de serveurs virtuels et de milliers de postes de travail virtuels. De précédents rapports avaient analysé des configurations exploitant des milliers de postes de travail virtuels pour couvrir le coût de ces contrôleurs. En lisant entre les lignes, vous remarquerez immédiatement que les coûts matériels par poste de travail virtuel augmentent très nettement lorsque la taille de telles configurations diminue. Pourtant, de la plupart des points de vue pratiques, ces configurations VDI de petite taille sont précisément celles les plus essentielles. D autre part, la taille de cette configuration peut également croître de manière linéaire jusqu à des milliers de postes de travail virtuels, éliminant ainsi les configurations distendues créées par la recherche de points d équilibre artificiels auxquels les coûts sont optimisés. Enfin, cette configuration utilise l outil d analyse VSI (Virtual Session Indexer) et repose sur le logiciel SANmelody de DataCore et la plate-forme de virtualisation Microsoft Hyper-V. L utilisation de Microsoft Hyper-V dans le cadre d une telle étude est inhabituelle car l on adopte en général la plate-forme VMware ESX pour le dimensionnement VDI. DataCore attend des résultats similaires avec ESX et les publiera dès qu ils seront disponibles. Le problème Les hyperviseurs actuels exploitent les réseaux de stockage (SAN) pour fournir l infrastructure de stockage nécessaire aux réseaux de machines virtuelles et hôtes. De telles infrastructures partagées servent à offrir portabilité, capacité de provisionnement et flexibilité aux machines virtuelles. De plus, le besoin de ces réseaux croît proportionnellement à la multiplication du nombre de machines virtuelles. Le besoin de configurations haute disponibilité croît au même rythme que le nombre de machines virtuelles, pour maintenir leur fonctionnement et pour éviter les pannes touchant, non pas une ou deux, mais peut-être des dizaines de machines. La prolifération des machines virtuelles renforce la dépendance des tâches de gestion courantes (par exemple, sauvegarde et migration) envers la fonctionnalité de gestion du stockage des réseaux SAN. Multipliez ces exigences par 10 ou 100 et nous obtenons la synergie entre les postes de travail virtuels et les réseaux SAN. Le problème des mises en œuvre de postes de travail virtuels réside dans le fait que les SAN sont souvent déployés avec de grands contrôleurs de stockage coûteux et des réseaux de stockage externe complexes. Bien qu ils présentent l avantage d assurer une évolutivité raisonnable, ils entraînent un coût minimal très élevé pour les projets VDI. Pour surmonter ce poids, les fournisseurs de matériel effectuent en général des tests avec un à plusieurs milliers de postes de travail virtuels. Les postes de travail virtuels n en restent qu à leurs débuts. De nombreuses entreprises, bien que comprenant les avantages potentiels de la technologie, lancent des programmes pilotes ou tentent d intégrer les déploiements VDI à des architectures existantes. Si la granularité de ces déploiements porte sur des milliers d unités, l utilisateur est alors contraint d exploiter non pas seulement un poste dans son intégralité, mais un éventail complet de postes sur un site, et ce avant même de savoir si la solution convient.

2 L alternative s avère tout aussi peu attractive. L utilisateur «prend sur soi» et accepte ce coût minimal élevé ainsi que la complexité d'un réseau SAN complet tout en exploitant un nombre de postes de travail virtuels bien inférieur au nombre optimal. Le coût de la mise en œuvre par poste de travail devient alors beaucoup plus conséquent qu il ne l aurait été si le modèle classique des postes de travail physiques avait été conservé. Cela ne s avère pas très engageant pour une nouvelle technologie censée réduire les coûts comme le soulignent de plus en plus de bloggeurs toujours pragmatiques. DataCore Cette étude est menée en exploitant l environnement des solutions logicielles de virtualisation du stockage de DataCore sur une plate-forme identique à celle des hyperviseurs hébergeant les postes de travail virtuels. Le logiciel de DataCore constitue une mise en œuvre complète d un réseau SAN haute disponibilité avec toutes les fonctionnalités nécessaires à une infrastructure d hébergement de machine virtuelle ainsi que des caractéristiques de performances exceptionnellement élevées. Outre ces fonctionnalités, le logiciel présente plusieurs caractéristiques recommandées pour cette application. La portabilité du logiciel lui permet de fonctionner comme une machine virtuelle sous Hyper-V ou ESX et également de s exécuter sous Windows Server 2008 au niveau du système d exploitation, en parallèle avec Hyper-V. Bien que cela signifie que le logiciel consomme des ressources matérielles communes, cela signifie également que la plupart des interconnexions de réseau SAN et des éléments de stockage (telles que le cache de bloc) sont déployés localement et virtuellement, sur une couche de base commune. Un tel modèle gagne ainsi plus de sa proximité avec ses clients qu il ne «coûte» par le fait de consommer des ressources matérielles communes, comme vous pourrez le constater en détail dans la partie Analyse des performances cidessous. En outre, le modèle décrit simplifie la configuration générale en évoluant de manière transparente : dès qu un nouvel hôte VDI est ajouté, les ressources de stockage nécessaires à son fonctionnement le sont également. De plus, ce mécanisme fonctionne dans les deux sens, éliminant ce qui pourrait constituer un sérieux problème lors du dimensionnement adéquat de l infrastructure. Rien de ceci ne devrait être interprété comme un «défi lancé» par les contrôleurs logiciels aux contrôleurs matériels. La solution DataCore fonctionne souvent de concert avec de tels contrôleurs matériels. Si l utilisateur a besoin de ces périphériques, alors il n y a aucun problème. Mais, s il n existe absolument aucun besoin pour de tels périphériques à la base des architectures VDI, si ni leur coût ni leur capacité ne parlent en faveur de leur intégration initiale, alors les contrôleurs matériels ne servent qu à altérer l architecture VDI. Les tests L outil de test utilisé est Virtual Session Indexer (VSI) Pro 2.1 de Login Consultants. L outil VSI devient à présent la norme pour ce type de charge de travail. Par rapport aux tests «à la carte» utilisés par plusieurs fournisseurs de stockage, et même par rapport aux données de suivi, l outil VSI semble n être qu un peu plus gourmand en E/S (et en particulier intense en écriture). L outil VSI crée également un ensemble fonctionnel plus important que ce à quoi l on pourrait s attendre de postes de travail physiques. L explication est simple : l outil VSI exécute chaque élément de son environnement de postes de travail émulé sur chaque poste de travail virtuel. En outre, la synchronisation des applications entre les postes de travail virtuels est formellement minimisée. Il est simple, globalement, de le justifier comme une simple standardisation des charges de travail nécessaire à la création d un environnement de test reproductible. L outil VSI, cependant, pèche par excès de prudence et s avère un peu plus exigeant que de nombreuses charges de travail propriétaires. Configuration La configuration utilisée dans l étude consiste en deux nœuds de serveur générique, chacun doté d une carte mère ASUS Z8PE-D18 Dual LGA, de deux processeurs Intel Xeon E5640 Westmere 2,66 GHz à quatre cœurs et d un disque d amorçage SATA 80 Go. Le coût total s élève à 2114,14 $ par serveur, hors mémoire DRAM et stockage des applications. En outre, chaque nœud est configuré avec 64 Go de mémoire DRAM DDR3 PC (à 1056,24 $) et 4 disques applicatifs : 2 disques durs SATA SAMSUNG HD103SJ et 2 disques durs SATA Western Digital VelociRaptor WD3000HLFS (393,60 $ pour les 4 disques durs). Le coût total du matériel serveur s élève donc à 3564,68 $ par machine et 7129,36 $ pour l ensemble de la configuration.

3 Deux disques SATA sont configurés en tant que pool de stockage, appartenant à SANmelody. Dans cette configuration, le logiciel SANmelody est exécuté au niveau du système d exploitation. Que SANmelody fonctionne à ce niveau ou sous forme de machine virtuelle ne fait que peu de différence. Dans ce cas, la première option est choisie pour la visibilité des tests. Le pool de stockage, une fois configuré, sert à héberger une «image maître» des postes de travail virtuels. Celle-ci est ensuite capturée grâce à la fonctionnalité de snapshot de DataCore, et chaque copie créée est présentée comme une LUN de démarrage sur les postes de travail virtuels. Des expériences ont tenté de déterminer si le fait d utiliser plusieurs images maîtres pouvait optimiser les performances. Ce fut non seulement inefficace, mais la présence de multiples images sources a en réalité augmenté la quantité de mémoire nécessaire à la gestion du jeu de pages de travail dans le cache de bloc DataCore. Enfin, l image initiale et ses snapshots sont mis en miroir sur le second serveur (grâce à la mise en miroir asynchrone de DataCore via iscsi) pour pouvoir atteindre le niveau requis de haute disponibilité. Cette configuration est alors non seulement protégée contre les pannes de stockage, mais les postes de travail virtuels peuvent également être redémarrés sur n importe quel autre serveur dans l éventualité d une défaillance plus critique. Deux disques SATA sont configurés en tant que second pool de stockage pour recevoir les données en miroir de l autre nœud. La configuration décrite ci-dessus est déployée avec quelques simples scripts qui lancent 110 postes de travail virtuels par serveur et transfèrent l ensemble de la configuration à l outil de test VSI. Nous vivons dans une ère dans laquelle les caractéristiques principales d une machine informatique de tout type sont gravées dans des puces et s avèrent donc presque identiques pour toute machine d un type donné. Cette configuration fut choisie afin de créer une référence de base au «plus petit dénominateur commun». Le choix des plates-formes de serveur et leurs coûts vont varier suivant le remplacement de tout élément, des solutions spécifiques aux optimisations pour l encombrement, la consommation d énergie et certaines «fonctions» d entreprise. Pourtant, aucune de ces variantes ne va modifier de manière sensible les performances, et ces variantes peuvent être perçues comme de simples différences de coûts par rapport à la référence présentée dans ce rapport.

4 Résultats La configuration ci-dessus fut en mesure d héberger 220 postes de travail utilisant l outil de test VSI Le rapport de présentation et de configuration des tests est reproduit intégralement en tant qu annexe à ce livre blanc. Analyse des performances : Co-hébergement L innovation majeure de ces tests repose sur l exploitation du système de virtualisation du stockage de DataCore sur les mêmes plates-formes matérielles utilisées pour héberger les postes de travail virtuels. Alors que certaines idées reçues pourraient suggérer que le logiciel DataCore deviendrait ainsi un concurrent pour les mêmes ressources limitées de la plate-forme matérielle, telles que la mémoire et les processeurs, de nombreuses expériences tendent à prouver le contraire. Dans chaque situation, de telles configurations cohébergées ont facilement surpassé les configurations dotées d un stockage externe. Les raisons sont simples à déterminer, a posteriori. L application des postes de travail virtuels n est pas particulièrement intensive en E/S et peut facilement être prise en charge par la solution DataCore en ne consommant que très peu de cycles de processeur. La suppression de la majeure partie du trafic des canaux externes entraîne une réduction accrue de ces demandes. En contrepartie, les défaillances au niveau du cache de bloc sont quasiment inexistantes, les surcharges des canaux disparaissent et les latences d E/S sont supprimées. La solution résidente SANmelody est rentable, sans aucune perte en termes de capacité ou de portabilité. Du point de vue de la mémoire, une dynamique similaire s applique. Les postes de travail virtuels offrent des ensembles fonctionnels d assez petite taille qui tendent à être intenses en lecture. Toutes les lectures s effectuant sur le volume source unique, qui est donc la base du volume système différentiel pour chaque poste de travail virtuel, l ensemble du regroupement effectue très correctement une mise en cache dans une taille de cache relativement petite. Des caches de taille supérieure engendrent un rendement décroissant. Enfin, l un des avantages prévisibles de ces types de configurations est qu elles sont intrinsèquement «autoréglables». Dès qu un groupe de postes de travail virtuels est ajouté, l infrastructure de stockage nécessaire à sa prise en charge l est également. Contrairement aux réseaux SAN génériques, qui présentent des besoins évolutifs et sont souvent organisés comme des réseaux de stockage indépendants, voire complexes, les besoins connus de l application VDI permettent dans ce cas de rendre l infrastructure de stockage en grande partie transparente. Disques La mise en cache d écriture étant efficace, le niveau de performances des disques requis peut baisser de manière significative. Lors de ces tests, 4 disques SATA furent utilisés et configurés en deux pools de deux disques DataCore. Le premier pool fut destiné au stockage principal et le second à la mise en miroir du nœud secondaire. L utilisation d une combinaison de disques à 7200 et tours-minute n est pas importante. Les quatre disques SATA (voire même 3) à 7200 tours-minutes présentant des caractéristiques similaires aux disques Samsung ont produit des résultats similaires. L importance que nous attachons à cette distinction est expliquée dans un autre document portant sur la création d une configuration de base. Nous nous opposions à utiliser d autres éléments que les composants SATA les plus standard et les plus facilement configurés. SAS, baies Fibre Channel, périphériques rapides, disques hybrides et SSD : tous ont leur place dans le monde réel et furent conçus pour délivrer des performances supérieures à la technologie SATA. Néanmoins, l intégration de ces périphériques lors de tests de base produit le même effet que la création d architectures VDI autour de telle ou telle baie de stockage. De telles optimisations pourraient être comparées à une source de confusion. Elles rendent non seulement les comparaisons difficiles, mais elles mènent à la subtile intrusion d une architecture matérielle spécifique dans un domaine dans lequel les exigences VDI elles-mêmes devraient primer. Mémoire Le coût de la mémoire DRAM représente une part importante des coûts totaux de la plate-forme de cette configuration. Ainsi, il paraît naturellement tentant de réduire la taille de la mémoire de chaque poste de travail virtuel, afin d optimiser le nombre de postes de travail que prend en charge chaque plate-forme. La difficulté est que la densité et la structure des coûts en évolution constante de la mémoire DRAM représentent la seule constante de notre marché... un fait qui parle en défaveur de l optimisation de la mémoire DRAM, et non en sa faveur. À cette difficulté s ajoute le fait que Microsoft et VMware offrent des fonctionnalités d hyperviseur permettant le «gonflement»

5 de la mémoire attribuée à chaque machine virtuelle. En effet, un type de mémoire virtuelle globale est créé entre les machines, bien que les mécanismes de mise en œuvre réels puissent différer. Enfin, les tests DataCore avec l outil VSI ont révélé que les postes de travail virtuels avec très peu d allocation de mémoire, si peu qu un ordinateur physique n aurait pu démarrer, fonctionnaient néanmoins normalement dans cette configuration. Après examen, il s est avéré que le fonctionnement du cache de bloc DataCore a créé une hiérarchie de pagination ne cherchant pas à empêcher «le thrashing», mais qui l a pratiquement absorbé en cas d adéquation avec des tailles de jeu de pages. Au final, ni le «gonflement» ni le «rapide thrashing» ne furent utilisés dans la mise en œuvre décrite. Cela a permis non seulement d effectuer de justes comparaisons pour analyser les données déjà publiées, mais a également évité l optimisation pour des modèles en grande partie propriétaires et indépendants de l opération de dimensionnement VDI. En un mot, le modèle conventionnel d allocation utilisé a évité les «diversions». La taille de cache réelle DataCore utilisée était de 4 Go. Alors que des caches de taille supérieure produisent de meilleurs résultats, celui-ci constituait le point auquel le rendement décroissant pouvait être clairement établi. En soustrayant cette utilisation et l attribution de mémoire pour Windows Server 2008, la mémoire DRAM restante était simplement divisée par le nombre de postes de travail résidents selon une allocation conventionnelle fixe. Coûts logiciels Il se peut que l on objecte que l utilisation par DataCore d un système logiciel de virtualisation du stockage au lieu d un contrôleur matériel doit entraîner le report du coût du logiciel pour réaliser une comparaison entre des éléments réellement comparables. Mais celui-ci apporte ses propres défis. La majorité des contrôleurs matériels testés s avèrent assez minimalistes. La plupart des fonctionnalités qu offre le logiciel SANmelody ne sont pas disponibles ou le sont à un coût additionnel pour les configurations en question. Ceci étant noté, le coût total du logiciel s élevait à 3848 $ par nœud ou 34,98 $ par poste de travail virtuel. Cela comprend le coût du système d exploitation Microsoft Server 2008 R2, qui héberge l environnement SANmelody et les postes de travail virtuels reposant sur Hyper-V, et le logiciel SANmelody DataCore. Le coût total de la configuration testée, incluant l ensemble des composants matériels et logiciels de son infrastructure mais ne comprenant pas le système d exploitation et les applications des postes de travail virtuels, s élève alors à 67,39 $ par poste de travail. Évolution Comme nous l avons abordé précédemment, le vrai problème ne résidait pas dans l évolution vers des milliers de postes de travail virtuels, mais dans leur adaptation à des configurations pratiques. Il est logiquement inutile de préciser qu il faut y parvenir sans alourdir sensiblement les coûts au niveau du poste et également sans renoncer au jeu de fonctionnalités du réseau SAN assurant portabilité, disponibilité et redondance des données. Sinon, tous les avantages de l infrastructure de postes de travail virtuels seraient compromis. La configuration DataCore décrite dans ce livre blanc est intéressante car elle assure des coûts faibles pour l infrastructure des 220 postes de travail en créant une solution de paire de serveurs hébergeant en parallèle les postes de travail virtuels et l infrastructure de stockage. Mais qu en est-il de l augmentation de la taille de cette configuration? Comment peut-on parvenir à des milliers de postes de travail, si cela est nécessaire? Et, point capital, est-il possible d y parvenir sans entraîner des coûts marginaux extrêmement variables ou de complexes reconfigurations? Pour obtenir des configurations de taille supérieure, une topologie DataCore connue sous le nom de «Star» est exploitée. Grâce à la topologie Star, l ajout d un troisième nœud sert à créer un centre ou un hub Star. Des nœuds supplémentaires sont alors ajoutés à la topologie Star. Chacun des nœuds de la topologie Star agit de la même manière qu auparavant, mais il met en miroir son contenu sur le nœud central plutôt que sur les autres nœuds. Celui-ci devient alors le seul point de contrôle de l ensemble de la configuration. Avec ce modèle, chaque nouveau serveur ajouté en un point de la topologie apporte ses propres périphériques de stockage, son infrastructure ainsi que son environnement VDI. Le modèle se configure automatiquement jusqu à ce que le nœud central ne puisse plus prendre en charge les données de miroir secondaire. Autre avantage, la plupart des phénomènes VDI dégénératifs, tels que les «boot storms», demeurent contenus dans des modules assez petits et gérables sans envahir l ensemble de la topologie. La simulation et l expérience initiale indiquent qu une simple topologie Star va adapter les performances (et les coûts par poste de travail virtuel) pour quelques milliers de postes de travail. DataCore publiera les résultats pour étayer ces conclusions initiales dès leur disponibilité.

6 Conclusion et orientations futures Ce livre blanc analyse une architecture VDI reposant sur le logiciel SANmelody de DataCore, Microsoft Windows Server 2008/Hyper-V et un matériel serveur standard. L outil Virtual Session Indexer (VSI) de Login Consultants est utilisé comme outil de test. L architecture étudiée diffère dans l ensemble de la majorité des résultats publiés par les autres fournisseurs de stockage. Au lieu de créer une configuration VDI autour d un contrôleur de stockage ou d une architecture SAN préexistante, le réseau SAN repose sur les serveurs VDI eux-mêmes. Les serveurs VDI agissent en particulier comme des serveurs de virtualisation. Les résultats obtenus sont près de dix fois supérieurs au ratio prix/performances des autres rapports publiés, tout en réduisant fortement le nombre de postes de travail virtuels (220) pour lequel de tels résultats sont atteints. L ensemble est obtenu sur le matériel le plus simple, au «plus petit dénominateur commun». Néanmoins, l environnement semble s adapter automatiquement, dans la mesure où il évite les refontes majeures en phase de croissance, tout en restant suffisamment modulaire pour tolérer les pannes matérielles, les reconfigurations et les anomalies VDI, telles que les «boot storms». Quelles sont les perspectives d avenir? Nombre d optimisations viennent immédiatement à l esprit. Dans le laboratoire de DataCore, nous avons augmenté avec succès la densité des postes de travail virtuels de plus de 50 %, pour atteindre le nombre de 175 postes de travail virtuels sur les mêmes plates-formes de serveurs. Optimisations de la mémoire, matériel amélioré et diverses «astuces» de réglage ont produit les résultats attendus. Néanmoins, des augmentations en termes de coût et de complexité se traduisent par un système à peine meilleur en termes de ratio prix/performances que le système testé ici. Pour répondre aux éventuelles objections, nous avons dû conclure à l optimisation suffisante de la configuration de base pour atteindre le palier des configurations VDI pratiques et conclure également que d autres optimisations de base n apporteraient que de faibles améliorations supplémentaires. Mais qu en est-il des optimisations de haut niveau? Bien, peut-être Le cohébergement du système d exploitation hôte, de l hyperviseur et du serveur de virtualisation, ainsi que des postes de travail virtuels, peut permettre une intégration plus étroite. D après notre expérience, toutefois, le fait que ceux-ci demeurent en grande partie indépendants offre à présent un genre tout à fait différent d «optimisation». L infrastructure de postes de travail virtuels présente un élément commun avec les autres aspects majeurs de l évolution informatique actuelle : le Cloud Computing. Les deux technologies visent à rassembler un très grand nombre de machines du même type c est-à-dire un grand nombre de plates-formes, dont les exigences en termes de ressources sont similaires et prévisibles à l avance. Au lieu d exigences inconnues et hétérogènes, l objectif repose sur des exigences connues et homogènes. Dans notre monde, ce qui est «connu» est également pré-configurable. Il devient ainsi possible d intégrer un nouveau niveau de virtualisation pour scinder et résoudre l extraordinaire fait qui frappe immédiatement toute personne tentant d exploiter une infrastructure VDI : l étendue de la gestion individuelle de machines à composants multiples qui sont néanmoins similaires, paradoxalement. Que se passerait-il si, au lieu de tenter de gérer individuellement des centaines ou des milliers de machines virtuelles, on pouvait les diviser en groupes, sous-groupes, «data centers virtuels» ou, selon le jargon de DataCore, en «ruches» arbitraires, puis traiter l ensemble de la ruche comme une seule entité? Dans ce cas, une «ruche» serait constituée d un groupe de postes de travail virtuels (50 ou 75 postes de travail virtuels), tous regroupés autour d un serveur de virtualisation DataCore et peut-être autour d autres serveurs nécessaires pour offrir des services locaux Tous ces serveurs seraient déployés en tant que machines virtuelles, configurés pour interagir les uns avec les autres et en toute transparence avec l environnement matériel sous-jacent. L ensemble de la ruche serait alors administré, migré et géré en tant qu une seule unité et le serveur de virtualisation agirait comme un seul «port» vers le monde externe. Du point de vue de l environnement, le seul facteur nécessaire résiderait dans une évaluation approximative de la capacité : deux «ruches» par ici, et quatre autres par là Voici l orientation future de notre stratégie.

7

8 Annexe Tests et configuration de l étude L outil de tests de performances utilisé pour déterminer le nombre optimal de postes de travail virtuels dans cette configuration est l outil de Login Consultants Virtual Session Indexer (VSI) version L outil Login VSI crée une charge de travail utilisateur simulée (Outlook, Internet Explorer, Excel, etc.) sur chaque poste de travail. Les postes de travail consignent les informations sur les performances dans un dossier commun partagé qui est analysé une fois les tests réalisés. La charge de travail utilisateur simulée démarre par l ouverture d une session de poste de travail distant sur le poste de travail virtuel. Dans ce cas, le programme VSI Launcher est utilisé dans sa configuration par défaut pour ouvrir les sessions, un poste de travail toutes les 60 secondes. La charge de travail utilisateur s exécute en boucle continue de 12 minutes jusqu à ce que toutes les sessions de postes de travail soient ouvertes et que la dernière ait fait l objet d une boucle. Une fois que tous les postes de travail virtuels ont exécuté leur charge de travail utilisateur simulée de manière simultanée et consigné leurs informations dans un dossier partagé, l outil VSI Analysis se lance. L outil compile les données dans Excel et produit un graphique ainsi que des tableaux de temps de réponse, indiquant ainsi une expérience utilisateur satisfaisante ou non. Informations de configuration : Postes de travail virtuels : Microsoft Windows 7 Enterprise x86 Configuration avec les optimisations VSI par défaut et celles recommandées dans le livre blanc du projet Virtual Reality Check «Projet VRC : Phase III» Étude : Login Consultants VSI Sept programmes VSI Launcher furent utilisés sur recommandation de l outil VSI. Tous les programmes Launcher fonctionnaient comme des machines virtuelles sur un hôte Hyper-V indépendant des hôtes exécutant les postes de travail virtuels. Le système d exploitation de ces machines virtuelles était Microsoft Server 2008 R2. DataCore SANmelody Le logiciel SANmelody était exécuté avec deux correctifs inclus dans la mise à jour de maintenance prévue pour ce trimestre.

9 Analyse de l outil de test VSI démontrant le fonctionnement opérationnel de 220 postes de travail. Copyright 2011 déposé par DataCore Software Corporation. Tous droits réservés. DataCore, le logo DataCore, reposant sur la technologie DataCore, SANsymphony et SANmelody sont des marques commerciales ou déposées de DataCore Software Corporation. Les autres noms de produit ou de service DataCore ou les logos mentionnés dans ce document sont des marques commerciales de DataCore Software Corporation. Les autres noms de produits, de services ou de sociétés mentionnés dans ce document peuvent être des marques commerciales de leurs détenteurs respectifs.